hello ... yeah, this is fairly complicated.
greg: can you send me how far you got? i would be curious to see how you have attacked this issue. i am still in the process of checking the codes. we somehow have to find a solution for that. otherwise we are in slight trouble here. it seems we have to solve it no matter what it takes. many thanks, hans On Jul 26, 2010, at 1:14 AM, Robert Haas wrote: > On Sun, Jul 25, 2010 at 6:40 PM, Greg Stark <gsst...@mit.edu> wrote: >> 2010/7/25 Robert Haas <robertmh...@gmail.com>: >>> 2010/7/25 PostgreSQL - Hans-Jürgen Schönig <postg...@cybertec.at>: >>>> >>>> On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote: >>>> >>>>> I think the right way to approach this is to teach the planner about >>>>> merge sorts. >> >> For what it's worth I think this is a belt-and-suspenders type of >> situation where we want two solutions which overlap somewhat. >> >> I would really like to have merge-append nodes because there are all >> sorts of plans where append nodes destroying the ordering of their >> inputs eliminates a lot of good plans. Those cases can be UNION ALL >> nodes, or partitions where there's no filter on the partition key at >> all. >> >> But for partitioned tables like the OPs the "real" solution would be >> to have more structured meta-data about the partitions that allows the >> planner to avoid needing the merge at all. It would also means the >> planner wouldn't need to look at every node; it could do a binary >> search or equivalent for the right partitions. > > Agreed on all points. > >>> Greg Stark had a patch to do this a while back called merge append, >>> but it never got finished... >> >> I was basically in over my head with the planner. I don't understand >> how equivalent classes are used or should be used and didn't >> understand the code I was pointed at as being analogous. It's probably >> not so complicated as all that, but I never really wrapped my head >> around it and moved onto tasks I could make more progress on. > > Yeah, I don't fully understand those either. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company > > -- > Sent via pgsql-hackers mailing list (firstname.lastname@example.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers