From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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 17:26:18 |
Message-ID: | 8211.1546622778@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2018-12-29 16:59:52 -0500, John Naylor wrote:
>>> I think 0001 with complete keyword lookup replacement is in decent
>>> enough shape to post. Make check-world passes. A few notes and
>>> caveats:
>> I tried to take this for a spin, an for me the build fails because various
>> frontend programs don't have KeywordOffsets/Strings defined, but reference it
>> through various functions exposed to the frontend (like fmtId()). That I see
>> that error but you don't is probably related to me using -fuse-ld=gold in
>> CFLAGS.
> I was just about to point out that the cfbot is seeing that too ...
Aside from the possible linkage problem, this will need a minor rebase
over 4879a5172, which rearranged some of plpgsql's calls of
ScanKeywordLookup.
While I don't think it's going to be hard to resolve these issues,
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-01-04 18:42:15 | Re: Making all nbtree entries unique by having heap TIDs participate in comparisons |
Previous Message | Pavel Stehule | 2019-01-04 16:47:47 | Re: Potentially undocumented behaviour change in Postgres 11 concerning OLD record in an after insert trigger |