|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>|
|Cc:||Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Joerg Sonnenberger <joerg(at)bec(dot)de>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> writes:
>> -There is a bit of a cognitive clash between $case_sensitive in
>> gen_keywordlist.pl and $case_insensitive in PerfectHash.pm. They each
>> make sense in their own file, but might it be worth using one or the
> Yeah, dunno. It seems to make sense for the command-line-level default of
> gen_keywordlist.pl to be "case insensitive", since most users want that.
> But that surely shouldn't be the default in PerfectHash.pm, and I'm not
> very sure how to reconcile the discrepancy.
Working on the fmgr-oid-lookup idea gave me the thought that
PerfectHash.pm ought to support fixed-length keys. Rather than start
adding random parameters to the function, I borrowed an idea from
PostgresNode.pm and made the options be keyword-style parameters. Now
the impedance mismatch about case sensitivity is handled with
my $f = PerfectHash::generate_hash_function(\(at)keywords, $funcname,
case_insensitive => !$case_sensitive);
which is at least a little clearer than before, though I'm not sure
if it entirely solves the problem.
Also, in view of finding that the original multiplier choices failed
on the fmgr oid problem, I spent a little effort making the code
able to try more combinations of hash multipliers and seeds. It'd
be nice to have some theory rather than just heuristics about what
will work, though ...
Barring objections or further review, I plan to push this soon.
regards, tom lane
|Next Message||Tom Lane||2019-01-09 19:44:24||Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)|
|Previous Message||Andreas Karlsson||2019-01-09 18:49:37||Re: insensitive collations|