| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ExplainModifyTarget doesn't work as expected |
| Date: | 2015-02-10 05:49:50 |
| Message-ID: | 54D99BFE.2000708@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Thanks!
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2015-02-10 06:19:04 | Re: Odd behavior of updatable security barrier views on foreign tables |
| Previous Message | Atri Sharma | 2015-02-10 02:35:02 | Re: GSoC 2015 - mentors, students and admins. |