Re: inconsistent results querying table partitioned by date

On Thu, 16 May 2019 at 13:51, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> How about we add one more bool, say, runtime_pruning_needed to
> GeneratePruningStepsContext and set it when we discover in
> match_clause_to_partition_key() that runtime pruning will be needed?  Then
> return it to make_partitionedrel_pruneinfo() using a new output parameter
> of gen_partprune_steps()?

I don't think this can be done the way you think. If we just have one
flag to say any run-time pruning is needed then we'd still need to
check op_volatile(opno) != PROVOLATILE_IMMUTABLE in
analyze_partkey_exprs() to see if an initial run-time prune is needed.
That means we might do two calls to op_volatile()!  The other one is
required to set the runtime_pruning_needed in
match_clause_to_partition_key().  We can't have an additional flag to
mark what do_exec_prune should get set to either since we only know
that once we check what Param types are in the Expr and if we do that
then that's the full-blown patch that we thought might be too much
churn.

I don't really see where this duplicate call is.  The patch calls
op_volatile() at the very most just once per pruning step.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services