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 по дате отправления: