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

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly
Date: 2018-04-09 10:15:28
Message-ID: 5ACB3D40.4040304@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

(2018/04/07 4:17), Andres Freund wrote:
> On 2018-03-05 17:07:10 -0500, Tom Lane wrote:
>> 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?

+1 because we cannot deny the possibility that the plan instability is
caused by such an unexpected behavior of postgres_fdw.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-04-09 10:17:55 Re: pruning disabled for array, enum, record, range type partition keys
Previous Message Amit Langote 2018-04-09 10:14:48 pruning disabled for array, enum, record, range type partition keys