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: Amit Langote <amitlangote09@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-05-12T13:57:44Z
Lists: pgsql-hackers
Amit Langote <amitlangote09@gmail.com> writes: > On Tue, May 12, 2020 at 5:25 AM Robert Haas <robertmhaas@gmail.com> wrote: >> 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. > IIUC, the idea is to have "dummy" columns in the top parent's > reltarget for every junk TLE added to the top-level targetlist by > child tables' FDWs that the top parent itself can't emit. But we allow > these FDW junk TLEs to contain any arbitrary expression, not just > plain Vars [1], so what node type are these dummy parent columns? We'd have to group the children into groups that share the same row-identity column type. This is why I noted way-back-when that it'd be a good idea to discourage FDWs from being too wild about what they use for row identity. (Also, just to be totally clear: I am *not* envisioning this as a mechanism for FDWs to inject whatever computations they darn please into query trees. It's for the row identity needed by UPDATE/DELETE, and nothing else. That being the case, it's hard to understand why the bottom-level Vars wouldn't be just plain Vars --- maybe "system column" Vars or something like that, but still just Vars, not expressions.) 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