Re: [PATCH] Optimize json_lex_string by batching character copying - Mailing list pgsql-hackers

From John Naylor
Subject Re: [PATCH] Optimize json_lex_string by batching character copying
Date
Msg-id CAFBsxsEDR6GctRTayurcGyR6d3GDjv0XGBqArPvrbO3H38T6Jg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Optimize json_lex_string by batching character copying  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: [PATCH] Optimize json_lex_string by batching character copying
Re: [PATCH] Optimize json_lex_string by batching character copying
List 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 by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Re: Fast COPY FROM based on batch insert
Next
From: Dilip Kumar
Date:
Subject: Re: making relfilenodes 56 bits