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

From Nathan Bossart
Subject Re: [PATCH] Optimize json_lex_string by batching character copying
Date
Msg-id 20220819204215.GA397534@nathanxps13
Whole thread Raw
In response to Re: [PATCH] Optimize json_lex_string by batching character copying  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: [PATCH] Optimize json_lex_string by batching character copying
List pgsql-hackers
On Fri, Aug 19, 2022 at 03:11:36PM +0700, John Naylor wrote:
> This is done. Also:
> - a complete overhaul of the pg_lfind8* tests
> - using a typedef for the vector type
> - some refactoring, name changes and other cleanups (a few of these
> could also be applied to the 32-byte element path, but that is left
> for future work)
> 
> TODO: json-specific tests of the new path

This looks pretty good to me.  Should we rename vector_broadcast() and
vector_has_zero() to indicate that they are working with bytes (e.g.,
vector_broadcast_byte())?  We might be able to use vector_broadcast_int()
in the 32-bit functions, and your other vector functions already have a
_byte suffix.

In general, the approach you've taken seems like a decent readability
improvement.  I'd be happy to try my hand at adjusting the 32-bit path and
adding ARM versions of all this stuff.

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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: use ARM intrinsics in pg_lfind32() where available
Next
From: Alvaro Herrera
Date:
Subject: Re: Schema variables - new implementation for Postgres 15