I just read the lead ups to this post - didn't see Tom and Greg's comments.
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.
I'd suggest we take this approach while also considering a more powerful set of append merge capabilities.
- Luke
Msg is shrt cuz m on ma treo
-----Original Message-----
From: Luke Lonergan [mailto:LLonergan@greenplum.com]
Sent: Saturday, October 27, 2007 03:14 PM Eastern Standard Time
To: Heikki Linnakangas; Anton
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1
And I repeat - 'we fixed that and submitted a patch' - you can find it in the unapplied patches queue.
The patch isn't ready for application, but someone can quickly implement it I'd expect.
- Luke
Msg is shrt cuz m on ma treo
-----Original Message-----
From: Heikki Linnakangas [mailto:heikki@enterprisedb.com]
Sent: Saturday, October 27, 2007 05:20 AM Eastern Standard Time
To: Anton
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1
Anton wrote:
> I repost here my original question "Why it no uses indexes?" (on
> partitioned table and ORDER BY indexed_field DESC LIMIT 1), if you
> mean that you miss this discussion.
As I said back then:
The planner isn't smart enough to push the "ORDER BY ... LIMIT ..."
below the append node.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings