Re: making update/delete of inheritance trees scale better
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Amit Langote <amitlangote09@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-05-11T20:25:38Z
Lists: pgsql-hackers
On Mon, May 11, 2020 at 4:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > If the parent is RTI 1, and the children are RTIs 2..6, what > > varno/varattno will we use in RTI 1's tlist to represent a column that > > exists in both RTI 2 and RTI 3 but not in RTI 1, 4, 5, or 6? > > Fair question. We don't have any problem representing the column > as it exists in any one of those children, but we lack a notation > for the "union" or whatever you want to call it, except in the case > where the parent relation has a corresponding column. Still, this > doesn't seem that hard to fix. My inclination would be to invent > dummy parent-rel columns (possibly with negative attnums? not sure if > that'd be easier or harder than adding them in the positive direction) > to represent such "union" columns. Ah, that makes sense. If we can invent dummy columns on the parent rel, then most of what I was worrying about no longer seems very worrying. I'm not sure what's involved in inventing such dummy columns, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited