From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | John Naylor <jcnaylor(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Joerg Sonnenberger <joerg(at)bec(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |
Date: | 2019-01-04 20:36:21 |
Message-ID: | 23471.1546634181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-01-04 12:26:18 -0500, Tom Lane wrote:
>> I'm wondering where we want to go with this. Is anyone excited
>> about pursuing the perfect-hash-function idea? (Joerg's example
>> function looked pretty neat to me.) If we are going to do that,
>> does it make sense to push this version beforehand?
> I think it does make sense to push this version beforehand. Most of
> the code would be needed anyway, so it's not like this is going to
> cause a lot of churn.
Yeah, I'm leaning in that direction too, first on the grounds of
"don't let the perfect be the enemy of the good", and second because
if we do end up with perfect hashing, we'd still need a table-generation
step. The build infrastructure this adds would support a generator
that produces perfect hashes just as well as what this is doing,
even if we end up having to whack the API of ScanKeywordLookup around
some more. So barring objections, I'll have a look at pushing this,
and then we can think about using perfect hashing instead.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-01-04 20:39:26 | Re: pgsql: Remove WITH OIDS support, change oid catalog column visibility. |
Previous Message | Tom Lane | 2019-01-04 20:31:11 | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |