Re: Runtime pruning problem

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Runtime pruning problem
Date: 2019-04-17 02:49:04
Message-ID: c4acce90-8265-c91f-065f-e4507ad054bd@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019/04/17 11:29, David Rowley wrote:
> On Wed, 17 Apr 2019 at 13:13, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> When you see this:
>>
>> explain select * from t1 where dt = current_date + 400;
>> QUERY PLAN
>> ────────────────────────────────────────────────────────────
>> Append (cost=0.00..198.42 rows=44 width=8)
>> Subplans Removed: 3
>> -> Seq Scan on t1_1 (cost=0.00..49.55 rows=11 width=8)
>> Filter: (dt = (CURRENT_DATE + 400))
>> (4 rows)
>>
>> Doesn't this give an impression that t1_1 *matches* the WHERE condition
>> where it clearly doesn't? IMO, contorting explain.c to show an empty
>> Append like what Hosoya-san suggests doesn't sound too bad given that the
>> first reaction to seeing the above result is to think it's a bug of
>> partition pruning.
>
> Where do you think the output list for EXPLAIN VERBOSE should put the
> output column list in this case? On the Append node, or just not show
> them?

Maybe, not show them? That may be a bit inconsistent, because the point
of VERBOSE is to the targetlist among other things, but maybe the users
wouldn't mind not seeing it on such empty Append nodes. OTOH, they are
more likely to think seeing a subplan that's clearly prunable as a bug of
the pruning logic.

Thanks,
Amit

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-04-17 03:33:07 log_planner_stats and prepared statements
Previous Message David Rowley 2019-04-17 02:29:17 Re: Runtime pruning problem