Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> writes:
> On 2015/02/03 15:32, Ashutosh Bapat wrote:
>> Instead, can we show all the relations that are being modified e.g
>> Update on child1, child2, child3. That will disambiguate everything.
> That's an idea, but my concern about that is the cases where there are a
> large number of child tables as the EXPLAIN would be difficult to read
> in such cases.
I concur, that would *not* be an improvement in readability. Moreover,
I don't think it really fixes the issue: what we want to show is a table
name in Modify that matches what the user wrote in the query. Given that
context, the user should be able to understand why some tables are listed
below that and others are not.
IIRC, this code was written at a time when we didn't have NO INHERIT check
constraints and so it was impossible for the parent table to get optimized
away while leaving children. So the comment in ExplainModifyTarget was
good at the time. But it no longer is.
I think your basic idea of preserving the original parent table's relid
is correct; but instead of doing it like this patch does, I'd be inclined
to make ModifyTable inherit from Scan not Plan, and use the scan.scanrelid
field to carry the parent RTI. Then you would probably end up with a net
savings of code rather than net addition; certainly ExplainModifyTarget
would go away entirely since you'd just treat ModifyTable like any other
Scan in this part of EXPLAIN.
regards, tom lane
