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
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
