"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

  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

Reply via email to