On 2018-03-05 17:07:10 -0500, Tom Lane wrote: > Joe Conway <m...@joeconway.com> writes: > > On 03/05/2018 11:19 AM, Tom Lane wrote: > >> Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to > >> rhinoceros' extra_config options, temporarily? Correlating that log > >> output with the log_statement output from the test proper would let > >> us confirm or deny whether it's autovacuum. > > > Done just now. Do you want me to force a run? > > Both of these runs > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros&dt=2018-03-05%2020%3A35%3A00 > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros&dt=2018-03-05%2021%3A45%3A02 > > appear to exonerate autovacuum, and the second seems to destroy the > behind-the-scenes-ANALYZE theory entirely, since there was no change > in the outputs of the extra instrumentation queries. (In theory > there's a window for ANALYZE to have occurred in between, but that's > not very credible.) > > So you can revert the rhinoceros config change if you like --- thanks > for making it so quickly! > > Meanwhile, I'm back to wondering what could possibly have affected > the planner's estimates, if pg_proc and pg_statistic didn't change. > I confess bafflement ... but we've now eliminated the autovacuum- > did-it theory entirely, so it's time to start looking someplace else. > I wonder if something in the postgres_fdw remote join machinery > is not as deterministic as it should be.
I wonder if temporarily changing postgres_fdw's test to specify an extra config that installs auto_explain in full aggressiveness (i.e. including costs etc) and enables debug3 logging could help narrow this down? - Andres
