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: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>,
Andrew Gierth <andrew@tao11.riddles.org.uk>,
John Naylor <jcnaylor@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-12-27T19:22:11Z
Lists: pgsql-hackers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: > RD parsers are not terribly hard to write. Sure, as long as they are for grammars that are (a) small, (b) static, and (c) LL(1), which is strictly weaker than the LALR(1) grammar class that bison can handle. We already have a whole lot of constructs that are at the edges of what bison can handle, which makes me dubious that an RD parser could be built at all without a lot of performance-eating lookahead and/or backtracking. > A smaller project might be to see if we can replace the binary keyword > search in ScanKeyword with a perfect hashing function generated by > gperf, or something similar. I had a quick look at that, too. Yeah, we've looked at gperf before, eg https://www.postgresql.org/message-id/20170927183156.jqzcsy7ocjcbdnmo@alap3.anarazel.de Perhaps it'd be a win but I'm not very convinced. I don't know much about the theory of perfect hashing, but I wonder if we could just roll our own tool for that. Since we're not dealing with extremely large keyword sets, perhaps brute force search for a set of multipliers for a hash computation like (char[0] * some_prime + char[1] * some_other_prime ...) mod table_size would 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