Re: Avoiding planning redundant backwards merges - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Avoiding planning redundant backwards merges
Date
Msg-id 87k5p91076.fsf@oxford.xeocode.com
Whole thread Raw
In response to Avoiding planning redundant backwards merges  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Avoiding planning redundant backwards merges
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: URGENT HELP about 'duration' stats
Next
From: Gregory Stark
Date:
Subject: Append nodes and orderings