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