Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

On 2018-03-05 17:07:10 -0500, Tom Lane wrote:
> Joe Conway <mail@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