From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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: Fri, 24 Mar 2017 11:26:27 -0400
Message-ID: <22215.1490369187@sss.pgh.pa.us> (raw)
In-Reply-To: <20170324020003.4rt63xty7xpb4akq@alap3.anarazel.de>
References: <20170322145240.vt2iolwt6vpmx33z@alap3.anarazel.de>
<31922.1490194838@sss.pgh.pa.us>
<28270.1490289299@sss.pgh.pa.us>
<20170323174004.a2ez7kygx5ngqxlp@alap3.anarazel.de>
<8011.1490305255@sss.pgh.pa.us>
<26088.1490315792@sss.pgh.pa.us>
<20170324004734.3a2dokbfofiz6ylu@alap3.anarazel.de>
<30270.1490318779@sss.pgh.pa.us>
<20170324013412.qy7ltnnqv5m7qiuc@alap3.anarazel.de>
<31825.1490320683@sss.pgh.pa.us>
<20170324020003.4rt63xty7xpb4akq@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Another modest proposal:
I'm not really sold on the approach of using EEOP_FETCHSOME opcodes to
trigger initial tupleslot de-forming. Certainly we want to have a single
slot_getsomeattrs call per source slot, but as-is, we need a separate
traversal over the expression tree just to precompute the max attribute
number needed. That can't be good for expression compile speed, and
it introduces nontrivial bug risks because the code that does that
is completely decoupled from the code that emits the EEOP_VAR opcodes
(which are what's really relying on the de-forming to have happened).
What do you think about a design like this:
* Drop the FETCHSOME opcodes.
* Add fields to struct ExprState that will hold the maximum inner,
outer, and scan attribute numbers needed.
* ExecInitExpr initializes those fields to zero, and then during
ExecInitExprRec, whenever we generate an EEOP_VAR opcode, we do e.g.
state->last_inner_attno = Max(state->last_inner_attno,
variable->varattno);
* ExecInitExprSlots, get_last_attnums_walker, etc all go away.
* In the startup segment of ExecInterpExpr, add
if (state->last_inner_attno > 0)
slot_getsomeattrs(innerslot, state->last_inner_attno);
if (state->last_outer_attno > 0)
slot_getsomeattrs(outerslot, state->last_outer_attno);
if (state->last_scan_attno > 0)
slot_getsomeattrs(scanslot, state->last_scan_attno);
This would be a little different from the existing code as far as runtime
branch-prediction behavior goes, but it's not apparent to me that it'd be
any worse. Also, for JIT purposes it'd still be entirely possible to
compile the slot_getsomeattrs calls in-line; you'd just be looking to a
different part of the ExprState struct to find out what to do.
regards, tom lane
--
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: tgl@sss.pgh.pa.us, andres@anarazel.de, hlinnaka@iki.fi, tomas.vondra@2ndquadrant.com
Subject: Re: WIP: Faster Expression Processing v4
In-Reply-To: <22215.1490369187@sss.pgh.pa.us>
* 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