"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
