Re: inconsistent results querying table partitioned by date

On 2019/05/16 10:00, David Rowley wrote:
> On Thu, 16 May 2019 at 12:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That's an interesting example, but how does it work now? I did not
>> observe any code in there that seems to be aware of cross-dependencies
>> between steps. Presumably somewhere we are combining those hash quals,
>> so couldn't we mark the combined step properly?
>
> In current HEAD we always generate steps for both quals when
> generating steps for planning and execution.
> partkey_datum_from_expr() just can't eval the qual when we're
> executing the steps during planning. My patch skips the step
> generation when the Expr is non-Const, so we save a few cycles and
> some memory allocation there. Remember that we don't reuse steps
> created for plan-time pruning in run-time pruning. A fresh set is
> created.

Given the way gen_partprune_steps() is designed [1], while it may be
possible to discard steps generated by run-time pruning that need not be
applied during execution because they would've already been fully applied
during plan-time pruning, it seems hard to keep around *partial* steps
generated during plan-time pruning and use them for run-time pruning after
filling missing expressions from run-time quals. Filling the missing
expressions into existing steps part seems hard.

Thanks,
Amit

[1] Any given PartitionPruneStepOp pruning step is built from a *set of*
clauses which have matched the required set of partitions keys (all keys
in the hash case and a prefix of keys in the range case). If the set of
clauses doesn't cover the required set of partition keys, no step will be
generated at all, which may happen if some of the clauses were run-time
clauses. The same set of clauses + parameterized path quals (if any)
might cover the required set and if so a step will be generated for
run-time pruning.