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