Re: Runtime pruning problem

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Runtime pruning problem
Date: 2019-04-16 12:09:52
Message-ID: CAKJS1f_4b9J7K7DSuZMkyga67OetfyAWz1xzYJd25HSf9-cijQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 16 Apr 2019 at 23:55, Yuzuko Hosoya <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> postgres=# explain analyze select * from t1 where dt = current_date + 400;
> QUERY PLAN
> ---------------------------------------------------------------------------------------
> Append (cost=0.00..198.42 rows=44 width=8) (actual time=0.000..0.001 rows=0 loops=1)
> Subplans Removed: 3
> -> Seq Scan on t1_1 (cost=0.00..49.55 rows=11 width=8) (never executed)
> Filter: (dt = (CURRENT_DATE + 400))
> Planning Time: 0.400 ms
> Execution Time: 0.070 ms
> (6 rows)
> ----
>
> I realized t1_1 was not scanned actually since "never executed"
> was displayed in the plan using EXPLAIN ANALYZE. But I think
> "One-Time Filter: false" and "Subplans Removed: ALL" or something
> like that should be displayed instead.
>
> What do you think?

This is intended behaviour explained by the following comment in nodeAppend.c

/*
* The case where no subplans survive pruning must be handled
* specially. The problem here is that code in explain.c requires
* an Append to have at least one subplan in order for it to
* properly determine the Vars in that subplan's targetlist. We
* sidestep this issue by just initializing the first subplan and
* setting as_whichplan to NO_MATCHING_SUBPLANS to indicate that
* we don't really need to scan any subnodes.
*/

It's true that there is a small overhead in this case of having to
initialise a useless subplan, but the code never tries to pull any
tuples from it, so it should be fairly minimal. I expected that using
a value that matches no partitions would be unusual enough not to go
contorting explain.c into working for this case.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-04-16 12:15:12 Re: pg_dump is broken for partition tablespaces
Previous Message Yuzuko Hosoya 2019-04-16 11:54:36 Runtime pruning problem