WIP Incremental JSON Parser - Mailing list pgsql-hackers

From Andrew Dunstan
Subject WIP Incremental JSON Parser
Date
Msg-id 7b0a51d6-0d9d-7366-3a1a-f74397a02f55@dunslane.net
Whole thread Raw
Responses Re: WIP Incremental JSON Parser
Re: WIP Incremental JSON Parser
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A tiny improvement of psql
Next
From: Tomas Vondra
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.