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:
>> The loop over steps, per se, isn't that expensive --- but extra syscache
>> lookups are. Or at least that's my gut feeling about it. If we just had
>> match_clause_to_partition_key mark the steps as being plan-time executable
>> or not, we could avoid the repeat lookup.
>
> okay, on re-think. I'm a little unsure of if you're mixing up "extra"
> and "repeat", we do need an "extra" lookup because we've discovered
> that strict ops are not safe to use during planning. I can't see
> around having this extra call. If you mean it's a repeat call, then
> it's really not, as we only do the op_volatile() check with
> forplanner=true. With forplanner = false we only call
> contain_var_clause() and contain_volatile_functions().

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()?

Thanks,
Amit