Re: add_path optimization

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I first tried just the compare_fuzzy_path_costs() change and really
>> couldn't measure any reliable difference. oprofile output for CVS HEAD
>> looks like

> Well, there's obviously something different between your case and
> mine, because in my query add_path was the #1 CPU hog and it wasn't
> close. I suspect my query had more joins - I'll take a look at yours.

Interesting. I'd like to see your example too, if you can publish it.
You had noted that add_path seemed to iterate clear to the end of the
list in most cases, which it's designed not to do, so there might be
something else going on in your example.

One other thought to roll around in your head: at the time that the
current add_path logic was designed, compare_pathkeys was ungodly
expensive, which is why the code tries to compare costs first.
We've since introduced the "canonical pathkey" representation, which
makes compare_pathkeys enough cheaper that it might not be insane
to do it in the other order. I don't immediately see an easy win
there, because as things are structured we typically want the cost
comparison result anyway for list sorting purposes. But maybe there's
a way around that.

regards, tom lane