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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
