Re: [PATCH] Optimize json_lex_string by batching character copying

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: [PATCH] Optimize json_lex_string by batching character copying
Дата
Msg-id 20220822212229.GA1129243@nathanxps13
обсуждение исходный текст
Ответ на Re: [PATCH] Optimize json_lex_string by batching character copying  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: [PATCH] Optimize json_lex_string by batching character copying  (Nathan Bossart <nathandbossart@gmail.com>)
Список pgsql-hackers
On Mon, Aug 22, 2022 at 09:35:34AM +0700, John Naylor wrote:
> Not at all! However, the 32-bit-element changes are irrelevant for
> json, and make review more difficult. I would suggest keeping those in
> the other thread starting with whatever refactoring is needed. I can
> always rebase over that.

Yeah, I'll remove those to keep this thread focused.

> - I like the idea of simplifying the assertions, but I can't get
> behind using platform lfind to do it, since it has a different API,
> requires new functions we don't need, and possibly has portability
> issues. A simple for-loop is better for assertions.

My main goal with this was improving readability, which is likely possible
without lfind().  I'll see what I can do.

> - A runtime elog is not appropriate for a compile time check -- use
> #error instead.

Will do.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: use ARM intrinsics in pg_lfind32() where available
Следующее
От: Peter Smith
Дата:
Сообщение: fix typo - empty statement ;;