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: | Postg토토 결과SQL |
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
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 |