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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
