Re: postgres_fdw bug in 9.6

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw bug in 9.6
Date: 2017-01-11 10:55:48
Message-ID: ac14dcb8-5bd6-2d17-f68b-a64daf430da6@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017/01/11 19:26, Ashutosh Bapat wrote:
> On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> On 2017/01/11 17:51, Ashutosh Bapat wrote:
>>> On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
>>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>>> On 2017/01/11 13:40, Ashutosh Bapat wrote:
>>>>> Or it can
>>>>> have foreign paths in there, which will need redirection. That's not
>>>>> very good.

>>>> Maybe I'm missing something, but redirection isn't a problem.

>>> Peformance wise it is, correctness-wise it is not. Why do we want to
>>> incur a hop, when we can avoid it.

>> ISTM that's solving a problem that hasn't been proven to be a problem.

> A hop will consume a function call worth CPU at least.

Is that a problem in practice?

>>>>> 2. Fix existing code by applying patch from [1]

>>>> As I said before, that might be fine for 9.6, but I don't think it's a
>>>> good
>>>> idea to search the pathlist because once we support parameterized foreign
>>>> join paths, which is on my TODOs, we would have to traverse through the
>>>> possibly-lengthy pathlist to find a local-join path, as mentioned in [3].

>>> I don't agree that pathlists will be long enough to make this a
>>> non-attractive solution. For parameterized foreign join paths, with
>>> the approach that this patch takes, we will require to search in two
>>> such pathlists, inner and outer.

>> Sorry, I don't understand this part.

> A parameterized join is built if the joining paths are parameterized
> as well. Thus building a parameterized local path would require one
> to search suitably parameterized paths in joining relations in their
> pathlists.

Yeah, I'm thinking to (1) create parameterized foreign-join paths from
the cheapest_parameterized_paths lists of the outer and inner rels, and
(2) create a local-join paths for any parameterized foreign-join path
from the component paths chosen from the lists in a similar way as
CreateLocalJoinPath creates an unparameterized local-join path from the
cheapest-total-cost paths of the outer and inner rels. That's the real
reason why I'm proposing to replace GetExistingLocalJoinPath with
CreateLocalJoinPath.

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-01-11 11:32:32 Re: PoC: Grouped base relation
Previous Message Simon Riggs 2017-01-11 10:36:09 Re: Proposal for changes to recovery.conf API