Re: [HACKERS] path toward faster partition pruning

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