Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)

Hi,

On 2018-12-20 00:54:39 +0000, Andrew Gierth wrote:
> >>>>> "John" == John Naylor <jcnaylor@gmail.com> writes:
> 
>  > On 12/18/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  >> I'd be kind of inclined to convert all uses of ScanKeyword to the
>  >> new way, if only for consistency's sake. On the other hand, I'm not
>  >> the one volunteering to do the work.
> 
>  John> That's reasonable, as long as the design is nailed down first.
>  John> Along those lines, attached is a heavily WIP patch that only
>  John> touches plpgsql unreserved keywords, to test out the new
>  John> methodology in a limited area. After settling APIs and
>  John> name/directory bikeshedding, I'll move on to the other four
>  John> keyword types.
> 
> Is there any particular reason not to go further and use a perfect hash
> function for the lookup, rather than binary search?

The last time I looked into perfect hash functions, it wasn't easy to
find a generator that competed with a decent normal hashtable (in
particular gperf's are very unconvincing). The added tooling is a
concern imo.  OTOH, we're comparing not with a hashtable, but a binary
search, where the latter will usually loose.  Wonder if we shouldn't
generate a serialized non-perfect hashtable instead. The lookup code for
a read-only hashtable without concern for adversarial input is pretty
trivial.

Greetings,

Andres Freund