Merge Append Patch merged up to 85devel

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Merge Append Patch merged up to 85devel
Date: 2009-07-05 15:02:29
Message-ID: 87ws6nrx4q.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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2009-07-05 15:02:50 Merge Append Patch merged up to 85devel
Previous Message Toshihiro Kitagawa 2009-07-05 13:49:40 Re: Did COPY performance regression solve in 8.4rc2?