Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0
Date
Msg-id 20170905185230.y6xwbeilrumx4qzl@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On 2017-09-05 19:43:33 +0100, Greg Stark wrote:
> On 5 September 2017 at 11:58, Konstantin Knizhnik
> <k.knizhnik@postgrespro.ru> wrote:
> >
> > I wonder if we can perform some optimization in this case (assuming that in
> > typical cases column either contains mostly non-null values, either mostly
> > null values).
> 
> If you really wanted to go crazy here you could do lookup tables of
> bits of null bitmaps. Ie, you look at the first byte of the null
> bitmap, index into an array and it points to 8 offsets for the 8
> fields covered by that much of the bitmap. The lookup table might be
> kind of large since offsets are 16-bits so you're talking 256 * 16
> bytes or 2kB for every 8 columns up until the first variable size
> column (or I suppose you could even continue in the case where the
> variable size column is null).

I'm missing something here. What's this saving?  The code for lookups
with NULLs after jitting effectively is
a) one load for every 8 columns (could be optimized to one load every  sizeof(void*) cols)
b) one bitmask for every column + one branch for null
c) load for the datum, indexed by register
d) saving the column value, that's independent of NULLness
e) one addi adding the length to the offset

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Fix performance of generic atomics
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing serverversion and psql version.