No title

On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:

Hmm. If I understand the patch correctly, it does not return any path
when merge join is allowed and there are merge clauses but no hash
clauses. In this case we will not create a foreign join path, loosing
some optimization. If we remove GetExistingLocalJoinPath, which
returns a path in those cases as well, we have a regression in
performance.

Ok, will revise, but as I mentioned upthread, I'm not sure it's a good idea
to search the pathlist to get a merge join even in this case. I'd vote for
creating a merge join path from the inner/outer paths in this case as well.
I think that would simplify the code as well.

Creating a new path requires 1. memory 2. requires a search in inner
and outer relations' pathlist (see my reply to your objection about
unparameterized paths) 3. spends CPU cycles in costing the path as
well as creating it. Searching for an existing path requires a search
in only one relation's pathlist. The path should be there so we don't
need to construct a new one.

The subject was removed from this reply for reasons unknown to me.
Will reply again on the relevant thread. Sorry for the inconvenience.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers