Re: inconsistent results querying table partitioned by date - Mailing list pgsql-bugs

From Amit Langote
Subject Re: inconsistent results querying table partitioned by date
Date
Msg-id ad3e1d3b-392c-d336-5bf1-256682874a9d@lab.ntt.co.jp
Whole thread Raw
In response to Re: inconsistent results querying table partitioned by date  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: inconsistent results querying table partitioned by date  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-bugs
On 2019/05/16 10:00, David Rowley wrote:
> On Thu, 16 May 2019 at 12:28, Tom Lane <tgl@sss.pgh.pa.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




pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND