Message-ID: <4c6cc0e1-b002-877b-c623-6c72dbcbdd8b@dunslane.net>
Date: Wed, 3 Jan 2024 11:55:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: WIP Incremental JSON Parser
Content-Language: en-US
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <7b0a51d6-0d9d-7366-3a1a-f74397a02f55@dunslane.net>
 <CA+TgmoZKqZ+xXN550e2DXM-F4ELCE+Ee=Ogy4pZZMhu9SBRmzQ@mail.gmail.com>
 <253cef9e-1360-a1a6-5091-ad4368b1b8cc@dunslane.net>
 <CA+TgmoYLi7RjjbWvBHa_9+2rVTuO4C1xPHJqzCdNUnHxR3-NdA@mail.gmail.com>
 <58987a44-878a-338b-31de-4543c90604f1@dunslane.net>
 <CA+TgmoZYB2xDi76w5EnuZHYtpyEEoq_Kt5c0rXPZ2XZ-MYhtxw@mail.gmail.com>
From: Andrew Dunstan <andrew@dunslane.net>
In-Reply-To: <CA+TgmoZYB2xDi76w5EnuZHYtpyEEoq_Kt5c0rXPZ2XZ-MYhtxw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/4c6cc0e1-b002-877b-c623-6c72dbcbdd8b%40dunslane.net>
Precedence: bulk


On 2024-01-03 We 10:12, Robert Haas wrote:
> 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.


OK, cleaning up in the client code will be much simpler, so let's go 
with that for now and revisit it later if necessary.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com