From: Andres Freund <andres@anarazel.de>
To: Douglas Doole <dougdoole@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: WIP: Faster Expression Processing v4
Date: Tue, 14 Mar 2017 15:16:48 -0700
Message-ID: <20170314221648.jrcgh5n7ld4ej2o7@alap3.anarazel.de> (raw)
In-Reply-To: <CADE5jYL7a8_b2LtwTJJk4ALLAKfCN1o9PWY3jS6D0e+3niOX8g@mail.gmail.com>
References: <20170307030137.lpo4japv5oqgbqpz@alap3.anarazel.de>
<2090fd00-4dec-7b42-f700-64308958504c@2ndquadrant.com>
<20170313080351.4g5oubxcj4xj5y7t@alap3.anarazel.de>
<fcdaa51b-e905-72e0-39dd-5e22f535a253@2ndquadrant.com>
<20170314065259.ffef4tfhgbsaieoe@alap3.anarazel.de>
<69b7bb0e-8dab-3d39-1a89-3c6ab6409f64@iki.fi>
<20170314173137.5r5jtgkgx6siuwsy@alap3.anarazel.de>
<58f9a171-edd7-e07d-3e21-52a451cd7c58@iki.fi>
<20170314185045.tpqddwrmedgknsqe@alap3.anarazel.de>
<CADE5jYL7a8_b2LtwTJJk4ALLAKfCN1o9PWY3jS6D0e+3niOX8g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi,
On 2017-03-14 22:03:45 +0000, Douglas Doole wrote:
> I do have one observation based on my experiments with your first version
> of the code. In my tests, I found that expression init becomes a lot more
> expensive in this new model. (That's neither a surprise, nor a
> concern.)
I suspect that's to a good degree because back then it'd often end up
trying the "new" stuff, but then fall back to the old machinery due to
unsupported operations. Which isn't a concern anymore, because now
there's full coverage.
Otherwise the cost aren't, according to my measurements, higher than
before, excepting that some stuff that happened at execution time is now
happening during initialization.
> In particular, the function ExprEvalPushStep() is quite hot. In my
> code I made the following changes:
>
> * Declare ExprEvalPushStep() "inline".
> * Remove the "if (es->steps_alloc == 0)" condition
> from ExprEvalPushStep().
> * In ExecInitExpr(), add:
> state->steps_alloc = 16;
> state->steps = palloc(sizeof(ExprEvalStep) * es->steps_alloc);
>
> I found that this cut the cost of initializing the expression by about 20%.
> (Of course, that was on version 1 of your code, so the benefit may well be
> different now.)
Hm. Right now ExprState's are allocated in several places - but we
could easily move that to a central place. Have a bit of a hard time
seing that that branch during *initialization* time is that expensive,
especially given that previously we allocated a lot of memory separately
too.
> On Tue, Mar 14, 2017 at 11:51 AM Andres Freund <andres@anarazel.de> wrote:
>
> > > Hmm. Could we make the instructions variable size? It would allow packing
> > > the small instructions even more tight, and we wouldn't need to obsess
> > over
> > > a particular maximum size for more complicated instructions.
> >
> > That makes jumps a lot more complicated. I'd experimented with it and
> > given it up as "not worth it".
> Back when I was at IBM, I spent a lot of time doing stuff like this. If you
> want to commit with the fixed size arrays, I'm happy to volunteer to look
> at packing it tighter as a follow-on piece of work. (It was already on my
> list of things to try anyhow.)
Yea, I think experimenting with that is a good idea. I just think this
is complicated enough, and I don't want to add a whole lot more
complexity for very debatable benefit.
> > If we were to try to do so, we'd also
> > not like storing the pointer and enum variants both, since it'd again
> > would reduce the density.
> From my experience, it's worth the small loss in density to carry around
> both the pointer and the enum - it makes debugging so much easier.
I found it annoying enough to print the instruction itself, due to the
union - so printing the opcode using a function isn't too bad...
Greetings,
Andres Freund
--
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: andres@anarazel.de, dougdoole@gmail.com, hlinnaka@iki.fi, tomas.vondra@2ndquadrant.com
Subject: Re: WIP: Faster Expression Processing v4
In-Reply-To: <20170314221648.jrcgh5n7ld4ej2o7@alap3.anarazel.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