Re: inconsistent results querying table partitioned by date

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> [ dont_prune_with_nonimmutable_opfuncs_during_planning_v3.patch ]

I started working through this, and changed some comments I thought could
be improved, and noticed that you'd missed out making the same changes
for ScalarArrayOp so I did that. However, when I got to the changes in
analyze_partkey_exprs, my bogometer went off. Why do we need to recheck
this, in fact why does that function exist at all? ISTM if we have used
a pruning qual at plan time there is no need to check it again at runtime;
therefore, it shouldn't even be in the list that analyze_partkey_exprs
is looking at.

I am wondering therefore whether we shouldn't do one of these two
things:

* Teach match_clause_to_partition_key to not emit plan-time-usable
quals at all if it is called with forplanner = false, or

* Add a bool field to PartitionPruneStep indicating whether the step
can be used at plan time, and use that to skip redundant checks at run
time. This would make more sense if we can then fix things so that
we only run match_clause_to_partition_key once per qual clause ---
I gather that it's now being run twice, which seems pretty inefficient.

Perhaps this implies too much code churn/restructuring to be reasonable
to consider right now, but I thought I'd ask. It sure seems like this
work is being done in a pretty inefficient and duplicative way.

regards, tom lane