Re: WIP Incremental JSON Parser
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-04T15:06:18Z
Lists: pgsql-hackers
On Wed, Jan 3, 2024 at 6:36 PM Nico Williams <nico@cryptonector.com> wrote: > On Tue, Jan 02, 2024 at 10:14:16AM -0500, Robert Haas wrote: > > It seems like a pretty significant savings no matter what. Suppose the > > backup_manifest file is 2GB, and instead of creating a 2GB buffer, you > > create an 1MB buffer and feed the data to the parser in 1MB chunks. > > Well, that saves 2GB less 1MB, full stop. Now if we address the issue > > you raise here in some way, we can potentially save even more memory, > > which is great, but even if we don't, we still saved a bunch of memory > > that could not have been saved in any other way. > > You could also build a streaming incremental parser. That is, one that > outputs a path and a leaf value (where leaf values are scalar values, > `null`, `true`, `false`, numbers, and strings). Then if the caller is > doing something JSONPath-like then the caller can probably immediately > free almost all allocations and even terminate the parse early. I think our current parser is event-based rather than this ... but it seems like this could easily be built on top of it, if someone wanted to. -- Robert Haas EDB: http://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