From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Soumyadeep Chakraborty <sochakraborty(at)pivotal(dot)io> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: expression evaluation improvements |
Date: | 2020-02-07 06:28:59 |
Message-ID: | 20200207062859.i5dntkegerp3pyoi@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-10-28 23:58:11 -0700, Soumyadeep Chakraborty wrote:
> > Cool! I'll probably merge that into my patch (with attribution of
> > course).
> >
> > I wonder if it'd nicer to not have separate C variables for all of
> > these, and instead look them up on-demand from the module loaded in
> > llvm_create_types(). Not sure.
>
> Great! It is much nicer indeed. Attached version 2 with your suggested
> changes.
> (v2-0001-Rely-on-llvmjit_types-for-building-EvalFunc-calls.patch)
> Used the same testing method as above.
I've comitted a (somewhat evolved) version of this patch. I think it
really improves the code!
My changes largely were to get rid of the LLVMGetNamedFunction() added
to each opcode implementation, to also convert the ExecEval* functions
we were calling directly, to remove the other functions in llvmjit.h,
and finally to rebase it onto master, from the patch series in this
thread.
I do wonder about adding a variadic wrapper like the one introduced here
more widely, seems like it could simplify a number of places. If we then
redirected all function calls through a common wrapper, for LLVMBuildCall,
that also validated parameter count (and perhaps types), I think it'd be
easier to develop...
Thanks!
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2020-02-07 06:35:13 | Re: WIP: expression evaluation improvements |
Previous Message | Kasahara Tatsuhito | 2020-02-07 06:07:51 | Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) |