• Tom Lane's avatar
    Restructure creation of run-time pruning steps. · 592d5d75
    Tom Lane authored
    Previously, gen_partprune_steps() always built executor pruning steps
    using all suitable clauses, including those containing PARAM_EXEC
    Params.  This meant that the pruning steps were only completely safe
    for executor run-time (scan start) pruning.  To prune at executor
    startup, we had to ignore the steps involving exec Params.  But this
    doesn't really work in general, since there may be logic changes
    needed as well --- for example, pruning according to the last operator's
    btree strategy is the wrong thing if we're not applying that operator.
    The rules embodied in gen_partprune_steps() and its minions are
    sufficiently complicated that tracking their incremental effects in
    other logic seems quite impractical.
    Short of a complete redesign, the only safe fix seems to be to run
    gen_partprune_steps() twice, once to create executor startup pruning
    steps and then again for run-time pruning steps.  We can save a few
    cycles however by noting during the first scan whether we rejected
    any clauses because they involved exec Params --- if not, we don't
    need to do the second scan.
    In support of this, refactor the internal APIs in partprune.c to make
    more use of passing information in the GeneratePruningStepsContext
    struct, rather than as separate arguments.
    This is, I hope, the last piece of our response to a bug report from
    Alan Jackson.  Back-patch to v11 where this code came in.
    Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com
plannodes.h 44 KB