From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
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:
Date: 2017-01-05 04:10:39
Message-ID: CAFjFpRcGZU4c-ykPZdmGOGMMkQJ3Ywhc6vnpVMO=oTFDddMeyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
>> 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.

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

Responses

  • Re: at 2017-01-05 04:14:41 from Ashutosh Bapat

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2017-01-05 04:14:41 Re:
Previous Message David Rowley 2017-01-05 04:03:31 Re: increasing the default WAL segment size