Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-27T13:19:53Z
Lists: pgsql-hackers
Hi, On 2018-12-26 14:03:57 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > My bet is, and has been for quite a while, that we'll have to go for a > > hand-written recursive descent type parser. > > I will state right up front that that will happen over my dead body. > > It's impossible to write correct RD parsers by hand for any but the most > trivial, conflict-free languages, and what we have got to deal with > is certainly neither of those; moreover, it's a constantly moving target. > We'd be buying into an endless landscape of parser bugs if we go that way. > It's *not* worth it. It's not exactly new that people end up moving to bison to recursive descent parsers once they hit the performance problems and want to give better error messages. E.g. both gcc and clang have hand-written recursive-descent parsers for C and C++ these days. I don't buy that we're inable to write a descent parser that way. What I *do* buy is that it's more problematic for the design of our SQL dialect, because the use of bison often uncovers ambiguities in new extensions of the language. And I don't really have a good idea how to handle that. Greetings, Andres Freund
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