On 17 May 2018 at 01:19, Robert Haas <robertmhaas@gmail.com> wrote:
> Hmm, that's actually not as bad as I thought. Thanks for the
> explanation. I think if I were going to try to improve things, I'd
> try to annotate the Append node with the name of the partitioned table
> that it's using for pruning in case #2 and case #3, and maybe
> something to indicate which type of pruning is in use. That would
> make it really clear whether pruning is enabled or not. The methods
> you mention above sort of require reading the tea leaves -- and it
> might not always be very easy to distinguish between cases where
> pruning is possible but nothing got pruned (imagine an inequality
> qual) and where it's not even possible in the first place.
>
> e.g.
>
> Append
> Execution-Time Pruning: order_lines (at executor startup)
> -> Index Scan ...
Perhaps Append should be shown as "Unordered Partitioned Table Scan on
<table>". That seems more aligned to how else we show which relation a
node belongs to. The partition being scanned is simple to obtain. It's
just the first item in the partitioned_rels List. (MergeAppend would
be an "Ordered Partitioned Table Scan")
I'm not really a fan of overloading properties with a bunch of text.
Multiple int or text properties would be easier to deal with,
especially so when you consider the other explain formats. Remember,
all 3 pruning methods could be used for a single Append node.
I guess doing work here would require additional code in the planner
to track how many relations were removed by both partition pruning and
constraint exclusion. Dunno if that would be tracked together or
separately. However, I'd prefer to have a clear idea of what exactly
the design should be before I go write some code that perhaps nobody
will like.
Unsure what you have in mind for the pruning done during actual
execution; just a yay or nay as to whether we're attempting it or not?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
