Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Дата
Msg-id 87lg4luimz.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)  (John Naylor <jcnaylor@gmail.com>)
Ответы Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)  (Andres Freund <andres@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)  (John Naylor <jcnaylor@gmail.com>)
Список pgsql-hackers
>>>>> "John" == John Naylor <jcnaylor@gmail.com> writes:

 > On 12/18/18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
 >> I'd be kind of inclined to convert all uses of ScanKeyword to the
 >> new way, if only for consistency's sake. On the other hand, I'm not
 >> the one volunteering to do the work.

 John> That's reasonable, as long as the design is nailed down first.
 John> Along those lines, attached is a heavily WIP patch that only
 John> touches plpgsql unreserved keywords, to test out the new
 John> methodology in a limited area. After settling APIs and
 John> name/directory bikeshedding, I'll move on to the other four
 John> keyword types.

Is there any particular reason not to go further and use a perfect hash
function for the lookup, rather than binary search?

-- 
Andrew (irc:RhodiumToad)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?