Re: ExplainModifyTarget doesn't work as expected

From: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ExplainModifyTarget doesn't work as expected
Date: 2015-02-06 08:40:10
Message-ID: CAFjFpRdKx4pAt25pQQZm5RfEXZMWG-TDmFNX9VTT9c2j2e2fug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2015-02-06 09:38:21 Re: PATCH: Reducing lock strength of trigger and foreign key DDL
Previous Message Michael Paquier 2015-02-06 08:38:55 Re: Simplify sleeping while reading/writing from client