Re: ExplainModifyTarget doesn't work as expected - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: ExplainModifyTarget doesn't work as expected
Date
Msg-id 54DC349B.9030404@lab.ntt.co.jp
Whole thread Raw
In response to Re: ExplainModifyTarget doesn't work as expected  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: ExplainModifyTarget doesn't work as expected  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2015/02/10 14:49, Etsuro Fujita wrote:
> On 2015/02/07 1:09, Tom Lane wrote:
>> 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.
>
> Will follow your revision.

Done.  Attached is an updated version of the patch.

Best regards,
Etsuro Fujita

Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Better error message on pg_upgrade checksum mismatches
Next
From: Noah Misch
Date:
Subject: Re: assessing parallel-safety