From: | Gregory Stark <stark(at)mit(dot)edu> |
---|---|
To: | Postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Merge Append Patch merged up to 85devel |
Date: | 2009-07-05 15:02:50 |
Message-ID: | 87vdm7rx45.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Here's a copy of the merge-append patch that I sent months ago merged up to
head. I haven't really added any additional functionality since then.
Heikki suggested I separate the Append and MergeAppend nodes into two executor
nodes. I had that half done in my tree but looking it over it leads to a lot
of duplicated code and a strange effect that there's on Path node but two
Executor nodes which seems strange. I'm not sure which way to go here but at
least for now I'm leaving it this way since it's less code to write. If we
want it the other way to commit then I'll do it.
The other pending question is the same I had back when I originally submitted
it. I don't really understand what's going on with eclasses and what
invariants we're aiming to maintain with them. I don't see a problem tossing
all the child relation attributes into the same eclass even though they're not
strictly speaking "equivalent". No join above the append path is going to see
the child attributes anyways. But that might be shortsighted as I'm not really
sure what the consequences are and what other uses we have envisioned for
eclasses in the future.
Attachment | Content-Type | Size |
---|---|---|
merge-append-85-v1.diff | text/x-diff | 28.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-05 21:34:49 | Re: Merge Append Patch merged up to 85devel |
Previous Message | Gregory Stark | 2009-07-05 15:02:29 | Merge Append Patch merged up to 85devel |