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 <john.naylor@2ndquadrant.com>
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-09T22:35:31Z
Lists: pgsql-hackers
John Naylor <john.naylor@2ndquadrant.com> writes: > On Tue, Jan 8, 2019 at 5:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The length macro was readily available there so I used it. AFAIR >> that wasn't true elsewhere, though I might've missed something. >> It's pretty much just belt-and-suspenders coding anyway, since all >> those arrays are machine generated ... > I tried using the available num_keywords macro in plpgsql and it > worked fine, but it makes the lines really long. Alternatively, as in > the attached, we could remove the single use of the core macro and > maybe add comments to the generated magic numbers. Meh, I'm not excited about removing the option just because there's only one use of it now. There might be more-compelling uses later. 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