From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: Large writable variables
In-reply-to: <20181015210259.3n7enpwlw3iy3apy@alap3.anarazel.de>
References: <20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de>
 <18430.1539635786@sss.pgh.pa.us>
 <20181015204557.2qqrh665cjqxvxv7@alap3.anarazel.de>
 <18995.1539636893@sss.pgh.pa.us>
 <20181015210259.3n7enpwlw3iy3apy@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 15 Oct 2018 14:02:59 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21008.1539638343.1@sss.pgh.pa.us>
Date: Mon, 15 Oct 2018 17:19:03 -0400
Message-ID: <21009.1539638343@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2018-10-15 16:54:53 -0400, Tom Lane wrote:
>> Yeah.  It also seems like doing it this way would improve locality of
>> access: the pieces of the giant string would presumably be in the same
>> order as the ScanKeywords entries, whereas with the current setup,
>> who knows where the compiler has put 'em or in what order.

> I assume you're talking about the offset approach. Performancewise I
> assume that my suggestion of inlining the names into the struct would be
> faster.  Are there many realistic cases where performance matters enough
> to warrant the size increase?

Doubt it, because there'd be an awful lot of wasted space due to the need
to set the struct size large enough for the longest keyword.  (Plus it
would likely not come out to be a power-of-2 size, slowing array
indexing.)  If you want this to be cache-friendly, I'd think the smaller
the better.

			regards, tom lane