On Thu, Jan 5, 2017 at 9:40 AM, Ashutosh Bapat
<ashutosh.ba...@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:
  • [HACKERS] Ashutosh Bapat
    • Re: [HACKERS] Ashutosh Bapat

Reply via email to