Re: Import Statistics in postgres_fdw before resorting to sampling. - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Import Statistics in postgres_fdw before resorting to sampling.
Date
Msg-id CADkLM=d5vmtZGnBC-Em-oiPi+EHYWzK1uWK4WLP_iyGnYPNGPA@mail.gmail.com
Whole thread Raw
In response to Re: Import Statistics in postgres_fdw before resorting to sampling.  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List 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.

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Flush some statistics within running transactions
Next
From: Martin Huang
Date:
Subject: Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors