On 2017/01/11 19:26, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 3:30 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
On 2017/01/11 17:51, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 1:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
