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

Re: Weird index or sort behaviour

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Weird index or sort behaviour
Date: 2009-08-18 16:41:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Tue, 18 Aug 2009, Tom Lane wrote:
> Matthew Wakeling <matthew(at)flymine(dot)org> writes:
>> I'm seeing some interesting behaviour. I'm executing a query where I
>> perform a merge join between two copies of the same table, completely
>> symmetrically, and the two sides of the merge are sourced differently.
> This is not as surprising as you think.  A mergejoin is *not*
> symmetrical between its two inputs: the inner side is subject to being
> partially rewound and rescanned when the outer side is advanced to a new
> row with the same merge key.  This means there is a premium on cheap
> rescan for the inner side that doesn't exist for the outer ... and a
> sort node is cheaper to rescan than a generic indexscan.

Very clever. Yes, that is what is happening. I'm surprised that the system 
doesn't buffer the inner side to avoid having to rescan each time, but 
then I guess you would have problems if the buffer grew larger than 

> It's impossible to tell from the data you provided whether the planner 
> was correct to pick a sort over an indexscan for the inner side, but the 
> fact that it did so is not prima facie evidence of a bug.  You could 
> force choice of the other plan via enable_sort = off and then compare 
> estimated and actual runtimes to see if the planner got it right.

Yes, it does get an almost unmeasureable amount slower if I force sorts 
off and nested loop (its next choice) off.


 $ rm core
 Segmentation Fault (core dumped)

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2009-08-18 16:49:37
Subject: Re: Weird index or sort behaviour
Previous:From: Tom LaneDate: 2009-08-18 15:05:23
Subject: Re: Weird index or sort behaviour

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