WIP Incremental JSON Parser
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-12-26T16:48:25Z
Lists: pgsql-hackers
Attachments
- json-incremental-parser-2023-12-26.patch (text/x-patch) patch 2023
Quite a long time ago Robert asked me about the possibility of an incremental JSON parser. I wrote one, and I've tweaked it a bit, but the performance is significantly worse that that of the current Recursive Descent parser. Nevertheless, I'm attaching my current WIP state for it, and I'll add it to the next CF to keep the conversation going. One possible use would be in parsing large manifest files for incremental backup. However, it struck me a few days ago that this might not work all that well. The current parser and the new parser both palloc() space for each field name and scalar token in the JSON (unless they aren't used, which is normally not the case), and they don't free it, so that particularly if done in frontend code this amounts to a possible memory leak, unless the semantic routines do the freeing themselves. So while we can save some memory by not having to slurp in the whole JSON in one hit, we aren't saving any of that other allocation of memory, which amounts to almost as much space as the raw JSON. In any case, I've had fun so it's not a total loss come what may :-) cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Commits
-
Post review fixes for test_json_parser test module
- ba3e6e2bca97 17.0 landed
-
Shrink test file for test_json_parser module
- b8a7bfa33324 17.0 landed
-
Add support for incrementally parsing backup manifests
- ea7b4e9a2a7c 17.0 landed
-
Introduce a non-recursive JSON parser
- 3311ea86edc7 17.0 landed
-
Use incremental parsing of backup manifests.
- 222e11a10ae9 17.0 landed