Re: WIP Incremental JSON Parser
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-03T15:12:37Z
Lists: pgsql-hackers
On Wed, Jan 3, 2024 at 9:59 AM Andrew Dunstan <andrew@dunslane.net> wrote: > Say we have a document with an array 1m objects, each with a field > called "color". As it stands we'll allocate space for that field name 1m > times. Using a hash table we'd allocated space for it once. And > allocating the memory isn't free, although it might be cheaper than > doing hash lookups. > > I guess we can benchmark it and see what the performance impact of using > a hash table might be. > > Another possibility would be simply to have the callback free the field > name after use. for the parse_manifest code that could be a one-line > addition to the code at the bottom of json_object_manifest_field_start(). Yeah. So I'm arguing that allocating the memory each time and then freeing it sounds cheaper than looking it up in the hash table every time, discovering it's there, and thus skipping the allocate/free. I might be wrong about that. It's just that allocating and freeing a small chunk of memory should boil down to popping it off of a linked list and then pushing it back on. And that sounds cheaper than hashing the string and looking for it in a hash bucket. -- 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