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

John Naylor <jcnaylor@gmail.com>

From: John Naylor <jcnaylor@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Andrew Gierth <andrew@tao11.riddles.org.uk>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-01-04T20:46:32Z
Lists: pgsql-hackers

Attachments

On 12/27/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If you really are hot about saving that other 440 bytes, the way to
> do it would be to drop the struct entirely and use two parallel
> arrays, an int16[] for value and a char[] (or better uint8[]) for
> category.  Those would be filled by reading kwlist.h twice with
> different definitions for PG_KEYWORD.  Not sure it's worth the
> trouble though --- in particular, not clear that it's a win from
> the standpoint of number of cache lines touched.

Understood. That said, after re-implementing all keyword lookups, I
wondered if there'd be a notational benefit to dropping the struct,
especially since as yet no caller uses both token and category. It
makes pl_scanner.c and its reserved keyword list a bit nicer, and gets
rid of the need to force frontend to have 'zero' token numbers, but
I'm not sure it's a clear win. I've attached a patch (applies on top
of v6), gzipped to avoid confusing the cfbot.

-John Naylor

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.