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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
