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: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Andrew Gierth <andrew@tao11.riddles.org.uk>,
John Naylor <jcnaylor@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-12-26T17:14:19Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > I'm kinda surprised that you haven't seen ScanKeywordLookup() in > there, but I agree with you that the size of the main parser tables is > a real issue, and that there's no easy solution. At various times > there has been discussion of using some other parser generator, and > I've also toyed with the idea of writing one specifically for > PostgreSQL. Unfortunately, it seems like bison is all but > unmaintained; the alternatives are immature and have limited adoption > and limited community; and writing something from scratch is a ton of > work. :-( Yeah, and also: SQL is a damn big and messy language, and so it's not very clear that it's really bison's fault that it's slow to parse. We might do a ton of work to implement an alternative, and then find ourselves no better off. 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