Subject: Re: WIP: Faster Expression Processing v4
To: Andres Freund <andres@anarazel.de>
References: <20161206034955.bh33paeralxbtluv@alap3.anarazel.de>
 <20170209003312.rr7atqepgbrf4xqe@alap3.anarazel.de>
 <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>
From: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, pgsql-hackers@postgresql.org
Message-ID: <58f9a171-edd7-e07d-3e21-52a451cd7c58@iki.fi>
Date: Tue, 14 Mar 2017 20:28:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170314173137.5r5jtgkgx6siuwsy@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 03/14/2017 07:31 PM, Andres Freund wrote:
> On 2017-03-14 16:58:54 +0200, Heikki Linnakangas wrote:
>> * How tight are we on space in the ExprEvalStep union? Currently, the
>> jump-threading preparation replaces the opcodes with the goto labels, but it
>> would be really nice to keep the original opcodes, for debugging purposes if
>> nothing else.
>
> There's nothing left to spare :(.  For debugging I've just used
> ExecEvalStepOp() - it's inconvenient to directly print the struct
> anyway, since gdb prints the whole union...

This comment above the union is not accurate:

> 	/*
> 	 * Data for an operation. Inline stored data is faster to access, but also
> 	 * bloats the size of all instructions. The union should be kept below 48
> 	 * bytes (so the entire struct is below 64bytes, a single cacheline on
> 	 * common systems).
> 	 */

On my x86-64 system, the whole struct is 64 bytes, but the union is only 
40 bytes. The fields before the union occupy 24 bytes. IOW, the union 
should be kept below 40 bytes, not 48.

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.

A compromise might be to have the fixed size, but have "continuation" 
opcodes for the more complicated instructions. An XmlExpr instruction, 
for example, could have an extra instruction after the primary one, just 
to hold more fields. When evaluating it, we would just increment the 
Program Counter by two instead of one, to skip over the extra instruction.

For reference, here are the sizes of all the structs in the union:

40: xmlexpr
40: scalararrayop
40: minmax
40: iocoerce
40: convert_rowtype
32: wholerow
32: rowcompare_step
32: row
32: func
32: fieldstore
32: domaincheck
32: boolexpr
32: arrayexpr
32: arraycoerce
24: casewhen
24: casethen
24: arrayref_checksubscript
16: grouping_func
16: fieldselect
16: constval
16: casetest
16: assign_var
16: arrayref
8: window_func
8: subplan
8: sqlvaluefunction
8: param
8: nulltest_row
8: assign_tmp
8: alternative_subplan
8: aggref
4: var
4: rowcompare_final
4: qualexpr
4: fetch
4: coalesce

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers