Hi, On Fri, Oct 26, 2018 at 6:40 AM David Rowley <david.row...@2ndquadrant.com> wrote: > > On 26 October 2018 at 16:52, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > I recall Ronan Dunklau and Julien Rouhaud had proposed a patch for this > > last year, but the partitioning-related planning code hadn't advanced then > > as much as it has today, so they sort of postponed working on it. > > Eventually their patch was returned with feedback last November. Here's > > the link to their email in case you wanted to read some comments their > > proposal and patch got, although some of them might be obsolete. > > > > https://www.postgresql.org/message-id/2401607.SfZhPQhbS4%40ronan_laptop > > Thanks. I wasn't aware, or ... forgot. Looks like back then was tricky > times to be doing this. Hopefully, the dust has settled a little bit > now.
Yes, back then I unfortunately had a limited time to work on that, and I had to spend all of it rebasing the patch instead of working on the various issue :( Sadly, I have even less time now, but I'll try to look at your patch this weekend! As far as I remember, the biggest problems we had was to handle multi-level partitionning, when the query is ordered by all or a subset of the partition keys, and/or with a mix of ASC/DESC clauses. It also required some extra processing on the cost part for queries that can be naturally ordered and contain a LIMIT clause, since we can estimate how many partitions will have to be scanned.
