Re: making update/delete of inheritance trees scale better
От | Tom Lane |
---|---|
Тема | Re: making update/delete of inheritance trees scale better |
Дата | |
Msg-id | 17606.1589291864@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: making update/delete of inheritance trees scale better (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: making update/delete of inheritance trees scale better
|
Список | 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
В списке pgsql-hackers по дате отправления: