Horton
Menu

Re: Import Statistics in postgres_fdw before resorting to sampling.

Corey Huinker <corey.huinker@gmail.com>

View thread
From: Corey Huinker <corey.huinker@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org, jkatz@postgresql.org, nathandbossart@gmail.com
Date: 2026-01-16T16:49:30Z
Lists: pgsql-hackers 
>
> Assuming following conditions to be true
> 1. object on the other side usually has statistics
> 2. it didn't when we queried.
>
> The reason for that situation is that the object was not analyzed
> before for the reasons you mention. Then why not just run ANALYZE and
> instantiate the statistics. That will happen only rarely.


I agree.


> Why do we
> need a table and server option to control that behaviour? Maybe you
> have already explained and I am not able to understand your answer.
>

I probably didn't explain it, but one reason for having the option is that
the role used to connect to the remote database might not have the
permissions to analyze tables in general, or that table in particular.

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.