2010/7/25 Robert Haas <robertmhaas@gmail.com>:
> 2010/7/25 PostgreSQL - Hans-Jürgen Schönig <postgres@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
