Re: Runtime pruning problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Runtime pruning problem
Date
Msg-id 8056.1564527407@sss.pgh.pa.us
Whole thread Raw
In response to Re: Runtime pruning problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Runtime pruning problem  (David Rowley <david.rowley@2ndquadrant.com>)
Re: Runtime pruning problem  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Runtime pruning problem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> This may be arguing for a change in ruleutils' existing behavior,
> not sure.  But when dealing with traditional-style inheritance,
> I've always thought that Vars above the Append were referring to
> the parent rel in its capacity as the parent, not in its capacity
> as the first child.  With new-style partitioning drawing a clear
> distinction between the parent and all its children, it's easier
> to understand the difference.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Runtime pruning problem
Next
From: David Rowley
Date:
Subject: Re: Runtime pruning problem