Re:

On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)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