Re: Import Statistics in postgres_fdw before resorting to sampling.

On Thu, Sep 24, 2026 at 8:50 AM Nurlan Tulemisov <nurlan(dot)tulemisov(at)gmail(dot)com>
wrote:

> Hi Corey,
> Thanks for the explanation.
>
>
>> So, basically you're proposing that we use the criteria of "the remote
>> server knows it should analyze this table, but hasn't yet for some reason"?
>
>
> Yes, the intention is to reuse the modification threshold PostgreSQL
> already uses for autoanalyze.
>

We could use the same reasoning to instead directly ANALYZE the remote
table before then attempting to read those remote stats. This might be
preferable because the imported stats are take less network bandwidth than
a table sample, and that allows for a much larger sample to be used on the
remote side (subject to their configuration, obviously).

>
> That's simple enough, but I wonder if that information wouldn't better be
>> used to defer the current local autoanalyze, using the thinking that we're
>> likely to get better stats after the remote catches up.
>
>
> My concern with deferring the local refresh is that exceeding this
> threshold does not guarantee that the remote ANALYZE will happen soon.
> Autovacuum could be disabled for the remote table, or its workers could be
> busy.
>

Or we could initiate it ourselves...I can revive that patch.

> As a smaller first step, would it make sense to emit a WARNING when
> importing statistics from a remote table whose modification count exceeds
> this threshold, while keeping the current import behavior?
>

That might have some merit too.

Keep the ideas coming.