Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Hi,

On 2018-12-20 00:54:39 +0000, Andrew Gierth wrote:
> >>>>> "John" == John Naylor <jcnaylor(at)gmail(dot)com> writes:
>
> > On 12/18/18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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