Re: making update/delete of inheritance trees scale better
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
Amit Langote <amitlangote09@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-05-11T20:22:40Z
Lists: pgsql-hackers
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. This concept would only need to exist within the planner I think, since after setrefs.c there'd be no trace of those dummy columns. > I think we have quite a bit of code that expects to be able to translate > between parent-rel expressions and child-rel expressions, and that's > going to be pretty problematic here. ... shrug. Sure, we'll need to be able to do that mapping. Why will it be any harder than any other parent <-> child mapping? The planner would know darn well what the mapping is while it's inventing the dummy columns, so it just has to keep that info around for use later. > Maybe your answer is - let's just fix all that stuff. That could well > be right, but my first reaction is to think that it sounds hard. I have to think that it'll net out as less code, and certainly less complicated code, than trying to extend inheritance_planner in its current form to do what we wish it'd do. regards, tom lane
Commits
-
Rework planning and execution of UPDATE and DELETE.
- 86dc90056dfd 14.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited