Merge Append Patch merged up to 85devel - Mailing list pgsql-hackers

From Gregory Stark
Subject Merge Append Patch merged up to 85devel
Date
Msg-id 87ws6nrx4q.fsf@oxford.xeocode.com
Whole thread Raw
Responses Re: Merge Append Patch merged up to 85devel  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Merge Append Patch merged up to 85devel  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.


--
  Gregory Stark
  http://mit.edu/~gsstark/resume.pdf

Attachment

pgsql-hackers by date:

Previous
From: Toshihiro Kitagawa
Date:
Subject: Re: Did COPY performance regression solve in 8.4rc2?
Next
From: Gregory Stark
Date:
Subject: Merge Append Patch merged up to 85devel