Re: Avoiding planning redundant backwards merges

"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. This would mean that
> only forward scans on ASC indexes and backward scans on DESC indexes
> would be considered to have "interesting" sort orders, and therefore
> in cases without any ORDER BY clause to worry about, the other indexscan
> path would not survive the initial competition in add_path. It'd be
> seen as having the same cost and worse ordering, and would be dropped.

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?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com