Re: inconsistent results querying table partitioned by date

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: inconsistent results querying table partitioned by date
Дата
Msg-id ad3e1d3b-392c-d336-5bf1-256682874a9d@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: inconsistent results querying table partitioned by date  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: inconsistent results querying table partitioned by date  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15804: Assertion failure when using logging_collector withEXEC_BACKEND