Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <jcnaylor@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2018-12-18T16:12:37Z
Lists: pgsql-hackers
John Naylor <jcnaylor@gmail.com> writes: > On 12/17/18, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Also, wouldn't we also adopt this technology for its unreserved keywords, >> too? > We wouldn't be forced to, but there might be other reasons to do so. > Were you thinking of code consistency (within pl_scanner.c or > globally)? Or something else? > If we did adopt this setup for plpgsql unreserved keywords, > ecpg/preproc/ecpg_keywords.c and ecpg/preproc/c_keywords.c would be > left using the current ScanKeyword struct for search. Using offset > search for all 5 types of keywords would be globally consistent, but > it also means additional headers, generated headers, and makefile > rules. I'd be kind of inclined to convert all uses of ScanKeyword to the new way, if only for consistency's sake. On the other hand, I'm not the one volunteering to do the work. regards, tom lane
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