Horton
Menu

Re: Import Statistics in postgres_fdw before resorting to sampling.

Etsuro Fujita <etsuro.fujita@gmail.com>

View thread
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org, jkatz@postgresql.org, nathandbossart@gmail.com
Date: 2026-04-02T11:05:41Z
Lists: pgsql-hackers 
On Thu, Apr 2, 2026 at 3:54 AM Corey Huinker <corey.huinker@gmail.com> wrote:

>> I think that that would be the user's fault, as it's the user's
>> responsibility to ensure that the existing stats for the remote table
>> are up-to-date.  From another perspective, not all users will be able
>> to operate in such a way, so I'm thinking of disabling this feature by
>> default.
>
> I'd like it to remain on by default, and the handling of this edge case can be made configurable in the future, so I'm fine with it for now.

The problem is not limited to this special case.  Consider cases when
1) the remote table that has many rows are heavily updated after it
got analyzed, and then 2) postgres_fdw imports its stats before it
gets re-analyzed.  The stats postgres_fdw imports would be stale,
causing plan degradation.  I don't think we should enable this feature
by default until we guarantee stats freshness in some way.

> Everything checks out over here.

Thanks for reviewing!

Best regards,
Etsuro Fujita

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. postgres_fdw: Replace buffers in RemoteAttributeMapping with pointers.

  2. Add support for importing statistics from remote servers.