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: Joerg Sonnenberger <joerg@bec.de>, John Naylor <jcnaylor@gmail.com>, pgsql-hackers@postgresql.org
Date: 2019-01-04T22:36:15Z
Lists: pgsql-hackers
Hi, On 2019-01-04 16:43:39 -0500, Tom Lane wrote: > Joerg Sonnenberger <joerg@bec.de> writes: > >> * What's the generator written in? (if the answer's not "Perl", wedging > >> it into our build processes might be painful) > > > Plain C, nothing really fancy in it. > > That's actually a bigger problem than you might think, because it > doesn't fit in very nicely in a cross-compiling build: we might not > have any C compiler at hand that generates programs that can execute > on the build machine. That's why we prefer Perl for tools that need > to execute during the build. However, if the code is pretty small > and fast, maybe translating it to Perl is feasible. Or perhaps > we could add sufficient autoconfiscation infrastructure to identify > a native C compiler. It's not very likely that there isn't one, > but it is possible that nothing we learned about the configured > target compiler would apply to it :-( I think it might be ok if we included the output of the generator in the buildtree? Not being able to add keywords while cross-compiling sounds like an acceptable restriction to me. I assume we'd likely grow further users of such a generator over time, and some of the input lists might be big enough that we'd not want to force it to be recomputed on every machine. 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