[HACKERS] - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject [HACKERS]
Date
Msg-id CAFjFpRcGZU4c-ykPZdmGOGMMkQJ3Ywhc6vnpVMO=oTFDddMeyA@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS]  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS]