Re: [PATCH] Optimize json_lex_string by batching character copying

John Naylor <john.naylor@enterprisedb.com>

From: John Naylor <john.naylor@enterprisedb.com>

To: Andres Freund <andres@anarazel.de>

Cc: Jelte Fennema <Jelte.Fennema@microsoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Merlin Moncure <mmoncure@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>

Date: 2022-07-06T08:58:44Z

Lists: pgsql-hackers

Attachments

v4-0001-Simplify-json-lexing-state.patch (text/x-patch) patch v4-0001
v4-0004-Use-vectorized-lookahead-in-json_lex_string-on-x8.patch (text/x-patch) patch v4-0004
v4-0003-Use-lookahead-path-in-json-string-lexing-for-the-.patch (text/x-patch) patch v4-0003
v4-0002-Build-json-strings-in-larger-chunks-during-lexing.patch (text/x-patch) patch v4-0002

On Wed, Jul 6, 2022 at 12:18 PM Andres Freund <andres@anarazel.de> wrote:

> I think before committing something along those lines we should make the
> relevant bits also be applicable when ->strval is NULL, as several functions
> use that (notably json_in IIRC). Afaics we'd just need to move the strval
> check to be around the appendBinaryStringInfo().

That makes sense and is easy.

> And it should simplify the
> function, because some of the relevant code is duplicated outside as well...

Not sure how far to take this, but I put the returnable paths inside
the "other" path, so only backslash will go back to the top.

Both the above changes are split into a new 0003 patch for easier
review, but in the end will likely be squashed with 0002.

-- 
John Naylor
EDB: http://www.enterprisedb.com

Commits

Speed up lexing of long JSON strings
- 0a8de93a48ce 16.0 landed
Add optimized functions for linear search within byte arrays
- e813e0e16852 16.0 landed
Build de-escaped JSON strings in larger chunks during lexing
- 3838fa269c15 16.0 landed
Simplify json lexing state
- 3de359f18f2b 16.0 landed