Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 6, 2014 at 3:39 AM, Marti Raudsepp <marti@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
