Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)
От | Andres Freund |
---|---|
Тема | Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables) |
Дата | |
Msg-id | 20190104202940.6w3wht5sn53xmesm@alap3.anarazel.de обсуждение исходный текст |
Ответ на | 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 writable variables)
|
Список | pgsql-hackers |
On 2019-01-04 12:26:18 -0500, Tom Lane wrote: > 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? 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: