Re: WIP: expression evaluation improvements

Поиск
Список
Период
Сортировка
От Soumyadeep Chakraborty
Тема Re: WIP: expression evaluation improvements
Дата
Msg-id CADwEdopeprsouU+33aHZzf67MkraQEm5K1x3sizsf1T8_Q7QgA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: expression evaluation improvements  (Soumyadeep Chakraborty <sochakraborty@pivotal.io>)
Ответы Re: WIP: expression evaluation improvements  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Hello Andres,

Attached is a patch on top of
v2-0026-WIP-expression-eval-relative-pointer-suppport.patch that eliminates the
const pointer references to fmgrInfo in the generated code.

FmgrInfos are now allocated like the FunctionCallInfos are
(ExprBuilderAllocFunctionMgrInfo()) and are initialized with expr_init_fmgri().

Unfortunately, inside expr_init_fmgri(), I had to emit const pointers to set
fn_addr, fn_extra, fn_mcxt and fn_expr.

fn_addr, fn_mcxt should always be the same const pointer value in between two identical
calls. So this isn't too bad?

fn_extra is NULL most of the time. So not too bad?

fn_expr is very difficult to eliminate because it is allocated way earlier. Is
it something that will have a const pointer value in between two identical
calls? (don't know enough about plan caching..I ran the same query twice and it
seemed to have different pointer values). Eliminating this pointer poses
a similar challenge to that of FunctionCallInfo->context. fn_expr is allocated
quite early on. I had tried writing ExprBuilderAllocNode() to handle the context
field. The trouble with writing something like expr_init_node() or something
even more specific like expr_init_percall() (for the percall context for aggs)
as these structs have lots of pointer references to further pointers and so on
-> so eventually we would have to emit some const pointers.
One naive way to handle this problem may be to emit a call to the _copy*()
functions inside expr_init_node(). It wouldn't be as performant though.

We could decide to live with the const pointers even if our cache key would be
the generated code. The caching layer could be made smart enough to ignore such
pointer references OR we could feed the caching layer with generated code that
has been passed through a custom pass that normalizes all const pointer values
to some predetermined / sentinel value. To help the custom pass we could emit
some metadata when we generate a const pointer (that we know won't have the same
const pointer value) to tell the pass to ignore it.

Soumyadeep
Вложения

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: [PATCH v1] pg_ls_tmpdir to show directories
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCH v1] pg_ls_tmpdir to show directories