Re: ExplainModifyTarget doesn't work as expected

Hi Ashutosh,

Thank you for the review!

On 2015/02/03 15:32, Ashutosh Bapat wrote:
> I agree that it's a problem, and it looks more severe when there are
> multiple children
> postgres=# create table parent (a int check (a < 0) no inherit);
> CREATE TABLE
> postgres=# create table child1 (a int check (a >= 0));
> CREATE TABLE
> postgres=# create table child2 (a int check (a >= 0));
> CREATE TABLE
> postgres=# create table child3 (a int check (a >= 0));
> CREATE TABLE
> postgres=# alter table child1 inherit parent;
> ALTER TABLE
> postgres=# alter table child2 inherit parent;
> ALTER TABLE
> postgres=# alter table child3 inherit parent;
> ALTER TABLE
> postgres=# explain update parent set a = a * 2 where a >= 0;
> QUERY PLAN
> ----------------------------------------------------------------
> Update on child1 (cost=0.00..126.00 rows=2400 width=10)
> -> Seq Scan on child1 (cost=0.00..42.00 rows=800 width=10)
> Filter: (a >= 0)
> -> Seq Scan on child2 (cost=0.00..42.00 rows=800 width=10)
> Filter: (a >= 0)
> -> Seq Scan on child3 (cost=0.00..42.00 rows=800 width=10)
> Filter: (a >= 0)
> (7 rows)
>
> It's certainly confusing why would an update on child1 cause scan on child*.

Yeah, I think so too.

> But I also think that showing parent's name with Upate would be
> misleading esp. when user expects it to get filtered because of
> constraint exclusion.
>
> 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.

Best regards,
Etsuro Fujita