"Tom Lane" <tgl@sss.pgh.pa.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