Re: [PATCH] Optimize json_lex_string by batching character copying
От | John Naylor |
---|---|
Тема | Re: [PATCH] Optimize json_lex_string by batching character copying |
Дата | |
Msg-id | CAFBsxsEDR6GctRTayurcGyR6d3GDjv0XGBqArPvrbO3H38T6Jg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Optimize json_lex_string by batching character copying (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: [PATCH] Optimize json_lex_string by batching character copying
Re: [PATCH] Optimize json_lex_string by batching character copying |
Список | pgsql-hackers |
On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Mon, Aug 22, 2022 at 02:22:29PM -0700, Nathan Bossart wrote: > > 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. > > Here's a new version of the patch with the 32-bit changes and calls to > lfind() removed. LGTM overall. My plan is to split out the json piece, adding tests for that, and commit the infrastructure for it fairly soon. Possible bikeshedding: Functions like vector8_eq() might be misunderstood as comparing two vectors, but here we are comparing each lane with a scalar. I wonder if vector8_eq_scalar() et al might be more clear. -- John Naylor EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: