| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Cc: | "pgsql-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: LIMIT/SORT optimization |
| Date: | 2007-02-07 13:51:01 |
| Message-ID: | 1170856261.3645.696.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-02-07 14:23:58 | Re: [PATCHES] writing new regexp functions |
| Previous Message | Alvaro Herrera | 2007-02-07 13:38:30 | Re: vcbuild needs strlcat |