Re: Ordered Append Node - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Ordered Append Node
Date
Msg-id 87zlx6hwht.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Ordered Append Node  (Markus Schiltknecht <markus@bluegap.ch>)
Responses Re: Ordered Append Node  (Markus Schiltknecht <markus@bluegap.ch>)
List pgsql-hackers
"Markus Schiltknecht" <markus@bluegap.ch> writes:

>> 1) Go through all subrels asking for any interesting pathkey lists. Gather up
>>    the union of all of these.
>
> I also tried to modify the Append node first, then figured that it might be
> better to base on the merge join node instead. While this seems farther away, I
> had the hope that a binary tree of such 'plain merge' nodes would require less
> comparisons in total.

It is kind of like a merge join but not quite. It's interleaving rows rather
than matching them up. It's more like the final merge of a sort which also
uses a heap to efficiently find the next value from the source tapes.

>> 3) It does seem to work when the columns in the subrels don't line up but I
>>    didn't do anything special to handle this case.
>
> Uh.. is there any use case for that? WRT partitioning certainly not, is there?

Not necessarily but it is something Postgres supports and I don't think we
want to break it. Actually it's useful for partitioned tables if you build the
new partition in a separate table and then add it to the partitioned table. In
that case you may have gone through several steps of adding columns and
dropping them to get the structure to line up.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: Ordered Append Node
Next
From: Simon Riggs
Date:
Subject: Re: Test lab