On 28 March 2018 at 22:29, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Also, I have redesigned how we derive partition indexes after running
> pruning steps. Previously, for each step we'd determine the indexes of
> "partitions" that are not pruned leading to a list partition not being
> pruned sometimes, as shown in the two recent examples. Instead, in the
> new approach, we only keep track of the indexes of the "datums" that
> satisfy individual pruning steps (both base pruning steps and combine
> steps) and only figure out the partition indexes after we've determined
> set of datums that survive all pruning steps. That is, after we're done
> executing all pruning steps. Whether we need to scan special partitions
> like null-only and default partition is tracked along with datum indexes
> for each step. With this change, pruning works as expected in both examples:
Smart thinking! Good to see that solved.
I'll try to look at v43 during my working day tomorrow, in around 9 hours time.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services