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: http://www.postgresql.org/mailpref/pgsql-hackers
