From: Andreas Seltenreich <seltenreich@gmx.de>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Improving executor performance
Date: Thu, 14 Jul 2016 23:03:10 +0200
Message-ID: <87r3aw0w6p.fsf@credativ.de> (raw)
In-Reply-To: <20160714181710.sh4nt3ylzp3f55wy@alap3.anarazel.de>
References: <20160624232953.beub22r6yqux4gcp@alap3.anarazel.de>
<20160714011850.bd5zhu35szle3n3c@alap3.anarazel.de>
<878tx42j1o.fsf@credativ.de>
<20160714181710.sh4nt3ylzp3f55wy@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund writes:
> The problem is that the previous form has a lot of ad-hoc analysis
> strewn in. The interesting part is getting rid of all that. That's what
> the new ExecInitExpr2() does. The target form can be both evaluated more
> efficiently in the dispatch manner in the patch, and quite simply
> converted to a JIT - without duplicating the analysis code. I did write
> a small ad-hoc x86 jit, and it was really quite straightforward this
> way.
Ja, I see the advantage when doing ad-hoc-JIT compilation.
> What did you do with JIT and expression evaluation? You basically just
> replaced the toplevel ExprState note with a different evalfunc, pointing
> into your code?
That's the plan, yes. I'm sorry there's no publishable code yet on the
the postgres side of things. Using libFirm[1], the plan is to.
1. Automatically generate Firm-IR for the static C code around
expression evaluation as well operators in the system catalog.
2. Construct IR for expression trees (essentially all the function calls
the executor would do).
3. Push libFirm's optimize button. At this stage, most of the
dispatching goes away by inlining the calls including functions from
the catalog implementing operators.
4. Generate code and replace the toplevel expression node with a funcall
node.
I did implement this recipe with a toy Forth interpreter to see whether
libFirm was up to the job (Nobody's done JIT with libFirm before). The
results were favorable[2]. Currently, a student at credativ is working
on applying these techniques to postgres.
regards,
Andreas
Footnotes:
[1] http://libfirm.org/
[2] https://korte.credativ.com/~ase/firm-postgres-jit-forth.pdf
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: seltenreich@gmx.de, andres@anarazel.de
Subject: Re: Improving executor performance
In-Reply-To: <87r3aw0w6p.fsf@credativ.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox