Well let's see what others think. Also, we might want to separate that
information on result relations heading probably.

On Fri, Feb 6, 2015 at 1:35 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
wrote:

> 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
>



-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Reply via email to