| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | Etsuro Fujita <etsuro(dot)fujita(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-01-16 16:49:30 |
| Message-ID: | CADkLM=d5vmtZGnBC-Em-oiPi+EHYWzK1uWK4WLP_iyGnYPNGPA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martin Huang | 2026-01-16 16:57:38 | Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors |
| Previous Message | Sami Imseih | 2026-01-16 16:44:48 | Re: Flush some statistics within running transactions |