| From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, 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: | 2025-12-15 10:01:44 |
| Message-ID: | CAPmGK172HWnpw+RZ4ZN7dmUAUGH1-9sg-bX981LTVZQ7F+F2bg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 15, 2025 at 5:01 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>> Ah, I mean the case where the foreign table is an inheritance parent
>> on the *local* side. In that case, the return would cause us to skip
>> the recursive ANALYZE (i.e., do_analyze_rel() with inh=true), leading
>> to no inherited stats. I agree that the case is minor, but I don't
>> think that that's acceptable.
> When such a corner case occurs (stats import configured to true, but table is an inheritance parent), should we raise an error, or raise a warning and return false on the CanImportStats() call? I guess the answer may depend on the feedback we get.
As mentioned upthread, the FDW API that I proposed addresses this
issue; even in such a case it allows the FDW to import stats, instead
of doing the normal non-recursive ANALYZE, and then do the recursive
ANALYZE, for the inherited stats.
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Vanns | 2025-12-15 10:22:49 | Re: [PATCH] Add support for SAOP in the optimizer for partial index paths |
| Previous Message | Heikki Linnakangas | 2025-12-15 09:55:10 | Re: POC: make mxidoff 64 bits |