Robert Haas <robertmh...@gmail.com> writes: > On Thu, Feb 6, 2014 at 3:39 AM, Marti Raudsepp <ma...@juffo.org> wrote: >> I guess it's because the patch undoes some optimizations in the >> mergejoin planner wrt caching merge clauses and adds a whole lot of >> code to find_mergeclauses_for_pathkeys. In other code paths the >> overhead does seem to be negligible.
> Yeah, I noticed that. My feeling is that those optimizations got put > in there because someone found them to be important, so I'm skeptical > about removing them. I put them in, and yeah they are important. Even with those, and even with the rather arbitrary heuristic restrictions that joinpath.c puts on what mergeclause lists to consider, the existing planner spends a whole lot of effort on mergejoins --- possibly disproportionate to their actual value. I think that any patch that removes those optimizations is not going to fly. If anything, it'd be better to reduce the number of mergejoins considered even further, because a lot of the possible plans are not usefully different. It's already the case that we expect indxpath.c to predict the useful orderings (by reference to query_pathkeys and available mergejoin clauses) and generate suitable paths, rather than trying to identify the orderings at join time. Can't that approach be extended to cover this technique? In any case, the bottom line is that we don't want this patch to cause the planner to consider large numbers of new but useless sort orderings. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers