Re: Runtime pruning problem

On Wed, 31 Jul 2019 at 10:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> OK, so experimenting, I see that it is a change: HEAD does
>
> regression=# explain verbose select * from part order by a;
>                                    QUERY PLAN
> ---------------------------------------------------------------------------------
>  Sort  (cost=362.21..373.51 rows=4520 width=8)
>    Output: part_p1.a, part_p1.b
>    Sort Key: part_p1.a
>    ->  Append  (cost=0.00..87.80 rows=4520 width=8)
>          ->  Seq Scan on public.part_p1  (cost=0.00..32.60 rows=2260 width=8)
>                Output: part_p1.a, part_p1.b
>          ->  Seq Scan on public.part_p2_p1  (cost=0.00..32.60 rows=2260 width=8)
>                Output: part_p2_p1.a, part_p2_p1.b
> (8 rows)
>
> The portion of this below the Append is fine, but I argue that
> the Vars above the Append should say "part", not "part_p1".
> In that way they'd look the same regardless of which partitions
> have been pruned or not.

That seems perfectly reasonable for Append / MergeAppend that are for
scanning partitioned tables. What do you propose we do for inheritance
and UNION ALLs?

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