| 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 | Resend email |
| 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
| 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 |