Re: inconsistent results querying table partitioned by date

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> 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.

Yeah.  It seems like the way to make some progress on this would be
to annotate the steps when they're generated as to whether they involve
any run-time component or not.  However, we might end up making multiple
calls anyway because of the possibility of parameterized paths having
additional qual clauses to work with, so I'm not clear on exactly how
we could reduce the number of times we do gen_partprune_steps.  It's
not something we could fix now in any case.

However, I'm still not real happy with analyze_partkey_exprs();
its analysis seems well short of ideal.  I notice that in the sort
of case suggested upthread, with more than one opclause contributing
to a step, it's entirely possible for it to report that both initial
and runtime pruning are needed even though only the latter is really
possible.  Perhaps this could be improved a bit by making the analysis
operate per-step rather than being totally per-expression.

Anyway, I've pushed David's patch now, on to look at Amit's.

            regards, tom lane