Re: [HACKERS] path toward faster partition pruning

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] path toward faster partition pruning
Дата
Msg-id 4c8af3a6-6d05-2fb6-2adb-b20b8731713e@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] path toward faster partition pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-hackers
On 2018/02/22 20:28, David Rowley wrote:
> On 22 February 2018 at 22:48, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> I'm having to add some NULL handling there for the run-time pruning
>>> patch but wondered if it was also required for your patch.
>>
>> Hmm, not sure why.  Can you explain a bit more?
> 
> hmm, yeah, but perhaps we should be discussing on the other thread...
> 
> With a prepared statement the Param will be unavailable until
> execution, in which case we don't do the const folding.

Ah right.

> A simple case is:
> 
> create table listp (a int) partition by list (a);
> create table listp1 partition of listp for values in(1);
> prepare q1 (int) as  select * from listp where a = $1;
> explain analyze execute q1(1); -- repeat 5 times.
> explain analyze execute q1(null); -- partkey_datum_from_expr() gets a
> NULL param via the call from nodeAppend.c

I wonder if NULLs should somehow be managed at a higher level, resulting
in the same behavior as const-folding in the optimizer produces?  In any
case, I suppose that would be something for the run-time pruning patch to
handle.

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Translations contributions urgently needed
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Translations contributions urgently needed