Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Luke Lonergan" <LLonergan(at)greenplum(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Anton" <anton200(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
Date: 2007-10-28 00:20:26
Message-ID: 87abq4ytrp.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


"Luke Lonergan" <LLonergan(at)greenplum(dot)com> writes:

> The approach we took was to recognize the ordering of child nodes and
> propagate that to the append in the special case of only one child (after
> CE). This is the most common use-case in 'partitioning', and so is an easy,
> high payoff low amount of code fix.

Ah yes, we should definitely try to prune singleton append nodes. On a lark I
had tried to do precisely that to see what would happen but ran into precisely
the problem you had to solve here with your pullup_vars function. That's one
of the functions which wasn't included in the original patch so I'll look at
the patch from the queue to see what's involved.

Actually currently it's not a common case because we can't eliminate the
parent partition. I have some ideas for how to deal with that but haven't
written them up yet.

In theory if we can preserve ordering across append nodes there's no good
reason to prune them. But generally I think simplifying the plan is good if
only to present simpler plans to the user.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2007-10-28 09:13:53 Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1
Previous Message Pablo Alcaraz 2007-10-27 22:31:18 Re: Speed difference between select ... union select ... and select from partitioned_table