> >> 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 1. requires memory 2. spends CPU cycles in costing and creating it 3. requires a search in inner and outer relations' pathlists (see my earlier reply). Searching for an existing path just requires a search in one relation's pathlist. The path should be there. Why do we want to spend extra resources in creating a new path when an old one exists and searching it is more efficient. -- 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