Re: Ordered Append Node

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ordered Append Node
Date: 2007-11-23 08:08:55
Message-ID: 47468A97.5040101@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Gregory,

Gregory Stark wrote:
> 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.

Well, maybe my point here is: why do you need the heap to sort? The
inputs you've got are already sorted, you only need to merge them. To me
this sounds very much like the final stage of a merge sort, which would
not require much memory.

IMO, a merge sort could easier be implemented by a binary tree zipper
node, as I had in mind. Leading to a plan like that (well, hey, this is
all made up):

Zipper (cost..., sort by public.t.i)
-> Zipper (cost .., sort by public.t.i)
-> Zipper (cost .., sort by public.t.i)
-> Index Scan using ti1 on t1
-> Index Scan using t12 on t2
-> Index Scan using ti2 on t3
-> Zipper (cost .., sort by public.t.i)
-> Index Scan using ti4 on t4
-> Index Scan using ti5 on t5

Every zipper node would simply have to keep the two top tuples from its
inputs in memory, compare them and return the best.

But maybe that's exactly how Knuth's polyphase merge sort internally
also merge their inputs (or runs). And perhaps it makes sense to show
the user just one simple append node instead of throwing a tree of
Zipper nodes at her. ;-)

> 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.

Agreed, especially because lining up the columns isn't that hard after all.

OTOH I think Postgres is way too flexible in how it allows partitioning
to be done and thus it often can't optimize it properly. I'd very much
like to teach it a stricter and simpler to use partitioning scheme than
what we have with constraint exclusion.

But that's pipe dreaming, and your improvement to the append node is
certainly a good step towards the right direction, keep up the good work!

Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Weimer 2007-11-23 08:49:48 Re: Ordered Append Node
Previous Message Thomas Güttler 2007-11-23 07:50:45 8.3beta3: Compile Warnings