Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Joerg Sonnenberger <joerg@bec.de>
From: Joerg Sonnenberger <joerg@bec.de>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Joerg Sonnenberger <joerg@bec.de>, John Naylor <jcnaylor@gmail.com>, pgsql-hackers@postgresql.org
Date: 2019-01-04T23:38:45Z
Lists: pgsql-hackers
On Fri, Jan 04, 2019 at 02:36:15PM -0800, Andres Freund wrote: > 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 :-( There is a pre-made autoconf macro for doing the basic glue for CC_FOR_BUILD, it's been used by various projects already including libXt and friends. > 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. This is quite reasonable as well. I wouldn't worry about the size of the input list at all. Processing the Webster dictionary needs something less than 0.4s on my laptop for 235k entries. Joerg
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