Re: [HACKERS] postgres_fdw bug in 9.6

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] postgres_fdw bug in 9.6
Date: 2018-01-17 10:32:35
Message-ID: 5A5F2643.6050905@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

(2018/01/16 6:38), Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jan 15, 2018 at 12:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Hm. Simple is certainly good, but if there's multiple rows coming
>>> back during an EPQ recheck then I think we have a performance problem.
>
>> You are correct ... I was wrong about that part, and said so in an
>> email on this thread sent about 45 minutes before yours.

I was wrong too.

>> However, I
>> still think the patch is a good fix for the immediate issue, unless
>> you see some problem with it. It's simple and back-patchable and does
>> not preclude further work anybody, including you, might want to do in
>> the future.

I still think so too.

> I'm also still pretty unhappy with the amount of useless planning work
> caused by doing GetExistingLocalJoinPath during path creation. It strikes
> me that we could likely replace the entire thing with some code that just
> reconstructs the join node's output tuple during EPQ using the rowmark
> data for all the base relations.

The join tuple would be reconstructed without a local join execution plan?

> Outer joins aren't really a problem:
> we could tell which relations were replaced by nulls because the rowmark
> values that bubbled up to the top went to nulls themselves.

Yeah, but we would need null-extension or projection...

> However,
> that's a nontrivial amount of work and probably wouldn't result in
> something we cared to back-patch, especially since it's not really a bug
> fix.

What do you think about a future extension to parameterized foreign paths?

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2018-01-17 10:48:21 Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning
Previous Message David Rowley 2018-01-17 09:19:45 Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning