On 28 March 2018 at 22:29, Amit Langote <langote_amit...@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
