From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Avoiding planning redundant backwards merges |
Date: | 2007-10-27 07:33:17 |
Message-ID: | 87k5p91076.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-10-27 08:18:16 | Append nodes and orderings |
Previous Message | Tom Lane | 2007-10-27 05:37:29 | Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1 |