Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
John Naylor <john.naylor@2ndquadrant.com>
From: John Naylor <john.naylor@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Andres Freund <andres@anarazel.de>, Joerg Sonnenberger <joerg@bec.de>,
David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-08T22:16:21Z
Lists: pgsql-hackers
On Tue, Jan 8, 2019 at 3:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I'll take a crack at separating into a module. I'll wait a bit in > > case there are any stylistic suggestions on the patch as it stands. > > I had a go at that myself. I'm sure there's plenty to criticize in > the result, but at least it passes make check-world ;-) Just a couple comments about the module: -If you qualify the function's module name as you did (PerfectHash::generate_hash_function), you don't have to export the function into the callers namespace, so you can skip the @EXPORT_OK setting. Most of our modules don't export. -There is a bit of a cognitive clash between $case_sensitive in gen_keywordlist.pl and $case_insensitive in PerfectHash.pm. They each make sense in their own file, but might it be worth using one or the other? -As for the graph algorithm, I'd have to play with it to understand how it works. In the committed keyword patch, I noticed that in common/keywords.c, the array length is defined with ScanKeywordCategories[SCANKEYWORDS_NUM_KEYWORDS] but other keyword arrays just have ...[]. Is there a reason for the difference?
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