| From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org, jkatz(at)postgresql(dot)org, nathandbossart(at)gmail(dot)com |
| Subject: | Re: Import Statistics in postgres_fdw before resorting to sampling. |
| Date: | 2026-04-02 11:05:41 |
| Message-ID: | CAPmGK16mVaiLRhRSJn7jp3X704MpYhb54iQ1CUrWd867xgCdyA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 2, 2026 at 3:54 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2026-04-02 11:14:37 | Re: [PATCH] analyze: move elevel calculation into do_analyze_rel() |
| Previous Message | Alexander Korotkov | 2026-04-02 11:02:40 | Re: POC: Parallel processing of indexes in autovacuum |