Re: Avoiding planning redundant backwards merges

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The idea I'm toying with is to make pathkeys_useful_for_merging()
>> consider only ASC pathkeys as useful for merging --- that is, only
>> pathkeys with pk_strategy = BTLessStrategyNumber.

> So the case that wouldn't be covered would be if you have a descending index
> on one table and an ascending index on another table and try to merge join
> them?

No, that still works. The point is that an ascending pathkey would come
from a forward scan on the regular index and a backward scan on the
descending index. Only those two paths, not their siblings
backward-scan-on-regular and forward-scan-on-descending, would survive
the initial planning round, and so we'd only consider merging in that
direction and not the other. However, in the event that the query asks
for ORDER BY merge-key DESC, we reverse all that so that only the other
two paths survive.

regards, tom lane