On Fri, Aug 26, 2022 at 10:26 AM Nathan Bossart
wrote:
>
> On Thu, Aug 25, 2022 at 04:41:53PM +0700, John Naylor wrote:
> > v3 applies on top of the v9 json_lex_string patch in [1] and adds a
> > bit more to that, resulting in a simpler patch that is more amenable
> > to additional SIMD-capable pl
On Thu, Aug 25, 2022 at 04:41:53PM +0700, John Naylor wrote:
> v3 applies on top of the v9 json_lex_string patch in [1] and adds a
> bit more to that, resulting in a simpler patch that is more amenable
> to additional SIMD-capable platforms.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aw
v3 applies on top of the v9 json_lex_string patch in [1] and adds a
bit more to that, resulting in a simpler patch that is more amenable
to additional SIMD-capable platforms.
[1]
https://www.postgresql.org/message-id/CAFBsxsFV4v802idV0-Bo%3DV7wLMHRbOZ4er0hgposhyGCikmVGA%40mail.gmail.com
--
John
On Thu, Aug 11, 2022 at 11:10:34AM +0700, John Naylor wrote:
>> I wonder if reusing a zero vector (instead of creating a new one every
>> time) has any noticeable effect on performance.
>
> Creating a zeroed register is just FOO PXOR FOO, which should get
> hoisted out of the (unrolled in this cas
On Thu, Aug 11, 2022 at 5:31 AM Nathan Bossart wrote:
>
> This is a neat patch. I don't know that we need an entirely separate code
> block for the USE_SSE2 path, but I do think that a little bit of extra
> commentary would improve the readability. IMO the existing comment for the
> zero accumul
On Wed, Aug 10, 2022 at 01:50:14PM +0700, John Naylor wrote:
> Here is an updated patch using the new USE_SSE2 symbol. The style is
> different from the last one in that each stanza has platform-specific
> code. I wanted to try it this way because is_valid_ascii() is already
> written in SIMD-ish s
new thread [was: WIP Patch: Add a function that returns binary JSONB as a bytea]
> I wrote:
> > We can also shave a
> > few percent by having pg_utf8_verifystr use SSE2 for the ascii path. I
> > can look into this.
>
> Here's a patch for that. If the input is mostly ascii, I'd expect that
> part o
