Skip site navigation (1) Skip section navigation (2)

Re: Avoiding planning redundant backwards merges

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding planning redundant backwards merges
Date: 2007-10-27 13:21:57
Message-ID: 14997.1193491317@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "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.

> 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?

No, that still works.  The point is that an ascending pathkey would come
from a forward scan on the regular index and a backward scan on the
descending index.  Only those two paths, not their siblings
backward-scan-on-regular and forward-scan-on-descending, would survive
the initial planning round, and so we'd only consider merging in that
direction and not the other.  However, in the event that the query asks
for ORDER BY merge-key DESC, we reverse all that so that only the other
two paths survive.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-27 13:32:02
Subject: Re: Definition of function base_yylex in version 8.1.4
Previous:From: Gregory StarkDate: 2007-10-27 12:53:59
Subject: min/max planner optimization

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group