> What I'm thinking of doing is truncating the recorded pathkeys of a path
> at the first sortkey that's not useful for either a higher-level
> mergejoin clause or the requested final output sort ordering. Then the
> logic inside add_path() wouldn't change, but it would only be considering
> useful pathkeys and not useless ones.
[ Sorry for the delay in replying. I was talking at Compaq.]
OK, here is my idea. Do the patch and post it to the hackers list so
people can see the scope of the change. Then, if no one objects, apply
it. We can always back it out, because no one else will be playing in
the optimizer. We can even back it out of a minor release if we find it
is a problem. Seems we don't want reports that queries are _slower_
than 7.0.X, and I can see how it would happen.
My quick question is that if we have a1=b1 and b1=c1, isn't the join
sorted by a1, b1, and c1, and threfore we don't get more sorted plans?
>
> I'm trying to resist the temptation to make this change right now :-).
> It's not quite a bug fix --- well, maybe you could call it a performance
> bug fix --- so I'm kind of thinking it shouldn't be done during beta.
> OTOH I seem to have lost the argument that Vadim shouldn't commit VACUUM
> performance improvements during beta, so maybe this should go in too.
> What do you think?
Did you lose the argument with Vadim? I haven't seen his vacuum commit
yet, though I certainly would like to. :-)
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026