On Wed, 15 May 2019 at 14:10, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Anyway, I'm attaching a squashed version of those two patches as
> 0001-Fix-bugs-in-pruning-with-composite-range-partition-k.patch. It
> applies as-is to both master and v11 branches.
I had a look at
0001-Fix-bugs-in-pruning-with-composite-range-partition-k.patch, and
due to my patch no longer generating pruning steps during planning for
non-consts, I don't think the test you have there is doing a very good
job of highlighting the bug. Maybe you could exploit this bug in the
tests by having both initplan run-time pruning and exec-time run-time
pruning run. Something like:
set plan_cache_mode = 'force_generic_plan';
prepare q1 (int) as select * from mc3p where a = $1 and abs(b) < (select 2);
explain (costs off) execute q1(1);
Additionally, I'm wondering if we should also apply the attached as
part of my dont_prune_with_nonimmutable_opfuncs_during_planning_v2.patch
patch. We should never get a non-Const in the pruning steps for
planning, so there's likely no point in doing a run-time check to
ensure we have a planstate. This code can execute quite often during
run-time pruning, once each time a parameter changes, which could be
each row. I think I'll go do that now, and also fix up that
forplanner comment you mentioned.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
