To: "Luke Lonergan" <LLonergan@greenplum.com>
Cc: "Heikki Linnakangas" <heikki@enterprisedb.com>,
	"Anton" <anton200@gmail.com>,  <pgsql-performance@postgresql.org>
Subject: Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
In-Reply-To: <C3E62232E3BCF24CBA20D72BFDCB6BF8044A24A3@MI8NYCMAIL08.Mi8.com>
	(Luke Lonergan's message of "Sat\, 27 Oct 2007 15\:28\:04 -0400")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <C3E62232E3BCF24CBA20D72BFDCB6BF8044A24A3@MI8NYCMAIL08.Mi8.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Sun, 28 Oct 2007 01:20:26 +0100
Message-ID: <87abq4ytrp.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


"Luke Lonergan" <LLonergan@greenplum.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