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

Re: LIMIT/SORT optimization

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: LIMIT/SORT optimization
Date: 2007-02-18 02:04:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Is there a newer version of this patch?


Gregory Stark wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > On Wed, 2007-02-07 at 10:49 +0000, Gregory Stark wrote:
> > > The two open issues (which are arguably the same issue) is how to get
> > > the information down to the sort node and how to cost the plan.
> > > Currently it's a bit of a hack: the Limit node peeks at its child and
> > > if it's a sort it calls a special function to provide the limit.
> > 
> > We can't lose the LIMIT node altogether, in case we have a paramterised
> > limit or a limit expression, so it does need to be in the executor.
> Right. The LIMIT node also implements offset and handles tricky border cases
> such as cursors that move past the edges. It would be pointless to duplicate
> the logic in tuplesort.c. The idea is to advise tuplesort.c when it can save
> work by not sorting more work than necessary, not duplicate the work of Limit.
> > Exploiting knowledge about adjacent plan types is already used in the
> > executor. If this seemed like it might be a generic trick, then I'd say
> > implement a generic function, but I don't see that it is.
> > 
> > We still want to push LIMIT/Sort down through an APPEND, but this won't
> > help us here - we'd need to do that in the planner.
> Hm, that's exactly the type of situation I was afraid of needing to have the
> information to propagate farther than an immediate child node and with more
> sophisticated rules. However as you point out that can be handled by doing
> optimizations that modify the plan tree. That keeps the scope of the
> optimization to a minimum: sort nodes directly under limit nodes. That's
> probably a better approach.
> -- 
>   Gregory Stark
>   EnterpriseDB
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-02-18 04:07:44
Subject: Re: [BUGS] BUG #2977: dow doesn't conform to ISO-8601
Previous:From: Bruce MomjianDate: 2007-02-18 01:35:21
Subject: Re: [HACKERS] Dead code in _bt_split?

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