Re: making update/delete of inheritance trees scale better

On Tue, May 12, 2020 at 10:57 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > On Tue, May 12, 2020 at 5:25 AM Robert Haas <robertmhaas(at)gmail(dot)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.

I understood the part about having a dummy parent column for each
group of children that use the same junk attribute. I think we must
group them using resname + row-identity Var type though, not just the
latter, because during execution, the FDWs look up the junk columns by
name. If two FDWs add junk Vars of the same type, say, 'tid', but use
different resname, say, "ctid" and "rowid", respectively, we must add
two dummy parent columns.

> (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.)

I suppose we would need to explicitly check that and cause an error if
the contained expression is not a plain Var. Neither the interface
we've got nor the documentation discourages them from putting just
about any expression into the junk TLE.

Based on an off-list chat with Robert, I started looking into whether
it would make sense to drop the middleman Append (or MergeAppend)
altogether, if only to avoid having to invent a representation for
parent targetlist that is never actually computed. However, it's not
hard to imagine that any new book-keeping code to manage child plans,
even though perhaps cheaper in terms of cycles spent than
inheritance_planner(), would add complexity to the main planner. It
would also be a shame to lose useful functionality that we get by
having an Append present, such as run-time pruning and partitionwise
joins.

--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com