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
- keyword-nostruct.patch.gz (application/x-gzip) patch
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
-
Use perfect hashing, instead of binary search, for keyword lookup.
- c64d0cd5ce24 12.0 landed
-
Reduce the size of the fmgr_builtin_oid_index[] array.
- 8ff5f824dca7 12.0 landed
-
Replace the data structure used for keyword lookup.
- afb0d0712f1a 12.0 landed