From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Markus Schiltknecht" <markus(at)bluegap(dot)ch>, "Florian Weimer" <fweimer(at)bfk(dot)de>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Ordered Append Node |
Date: | 2007-11-23 16:54:09 |
Message-ID: | 10493.1195836849@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>> Markus Schiltknecht wrote:
>>> And why do you need lots of heap memory to do that? Anything wrong with the
>>> zipper approach I've outlined upthread?
>>
>> We're talking about a binary heap, with just one node per partition. AFAICT
>> it's roughly the same data structure as the zipper tree you envisioned, but not
>> implemented with separate executor nodes for each level.
> Not quite the same since the Executor-based implementation would have a static
> tree structure based on the partitions. Even if the partitions are all empty
> except for one or two you would still have to push the result records through
> all the nodes for the empty partitions.
Also, the overhead per executor node visit is not exactly trivial.
I think that "zipper" scheme would be quite slow compared to a standard
heap merge within a single node.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-11-23 18:29:40 | buildfarm member tapir failing PLCheck in 8.1 branch |
Previous Message | Tom Lane | 2007-11-23 16:48:44 | Re: 8.3beta3: Compile Warnings |