Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
От | Tom Lane |
---|---|
Тема | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) |
Дата | |
Msg-id | 8211.1546622778@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: reducing the footprint of ScanKeyword (was Re: Large writable variables) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
|
Список | pgsql-hackers |
I wrote: > Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: