Re: WIP: expression evaluation improvements

From: Soumyadeep Chakraborty <sochakraborty(at)pivotal(dot)io>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: expression evaluation improvements
Date: 2020-03-03 20:21:44
Message-ID: CADwEdopeprsouU+33aHZzf67MkraQEm5K1x3sizsf1T8_Q7QgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
v1-0001-jit-Eliminate-const-pointer-to-fmgrinfo.patch application/octet-stream 16.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-03-03 20:23:13 Re: [PATCH v1] pg_ls_tmpdir to show directories
Previous Message Justin Pryzby 2020-03-03 20:01:17 Re: [PATCH v1] pg_ls_tmpdir to show directories