Re: LIMIT/SORT optimization - Mailing list pgsql-patches

From Simon Riggs
Subject Re: LIMIT/SORT optimization
Date
Msg-id 1170856261.3645.696.camel@silverbirch.site
Whole thread Raw
In response to LIMIT/SORT optimization  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: LIMIT/SORT optimization  (Gregory Stark <gsstark@mit.edu>)
List pgsql-patches
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.

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.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: vcbuild needs strlcat
Next
From: Tom Lane
Date:
Subject: Re: Feature: POSIX Shared memory support