Horton

Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: John Naylor <jcnaylor@gmail.com>, pgsql-hackers@postgresql.org
Date: 2018-12-22T18:28:35Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2018-12-22 12:20:00 -0500, Tom Lane wrote:
>> I like that idea a *lot*, actually, because it offers the opportunity
>> to decouple this mechanism from all assumptions about what the
>> auxiliary data for a keyword is.

> OTOH, it doubles or triples the number of cachelines accessed when
> encountering a keyword.

Compared to what?  The current situation in that regard is a mess.

Also, AFAICS this proposal involves the least amount of data touched
during the lookup phase of anything we've discussed, so I do not even
accept that your criticism is correct.  One extra cacheline fetch
to get the aux data for a particular keyword after the search is not
going to tip the scales away from this being a win.

			regards, tom lane

Commits

  1. Use perfect hashing, instead of binary search, for keyword lookup.

  2. Reduce the size of the fmgr_builtin_oid_index[] array.

  3. Replace the data structure used for keyword lookup.