Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rL2yi-005pIN-6r for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2024 15:16:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rL2yg-0062ZO-Pn for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Jan 2024 15:16:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rL2vO-005yrz-E7 for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2024 15:12:54 +0000 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rL2vL-00FLzT-T8 for pgsql-hackers@lists.postgresql.org; Wed, 03 Jan 2024 15:12:53 +0000 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40d60ad5f0bso66625295e9.0 for ; Wed, 03 Jan 2024 07:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704294770; x=1704899570; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mfjZPIODKxTKVjyCLo8MwT1YJ1MVdkWV2Pqqjk67fzE=; b=GrEGn0MiUwLYKC+Z8ik9mO/ytlwKNxBxgYKMuKQlfA9Y3InFMG+2IGcLlqn/clWoz7 wXb4OreOW55mieYARDItyg7fz92qmd1rHm1F27HThJbOzjLuxyl2dHZE/grELgmabixh X2PDesussQqJp5Ut6B+kBntBSP/9mTEAfIqbbGGkqwp7wXNOLkJkjS/2eLpuyM7RVlpl cyxLanlZ9+DXvzlovpUm1wCSbusrUpAnVoE7OkAqzmIwdzPzKJW61tnWhEofzwEs0+rv q28xEZdJhZaeMXBoHirXEVzvYC1ieUn4M/LXxh2Xt004Gnbf/4Vc/u+hBYR8wdZRjloP usEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704294770; x=1704899570; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mfjZPIODKxTKVjyCLo8MwT1YJ1MVdkWV2Pqqjk67fzE=; b=OUkuNlaC23XdYCqLlzvlpPsFr1CpzXAy/YohHN9kSpKekS0czecNTUPNqqSxnzEoZX d6pczMIafC/Er5PJMB2h4qa+4Xp2LC56nvtCrJ4pTF0JRS7jNWM8dMt4oLqTwAYbaSIo WmoSTOdWfBkq4tACkqyNVMmVsfi3oCM+QG8f/3MSwMd/6ztPjAZNB5VMSM90DcajxE4K qpgotUt1gircP56voAsFBYtBhXM/7xC2VOOucz+QC4bdMnAPUDpy1mQY1RMvAfZicw+2 cz2wYfzdS50WMmkjmwfpR3hfFA38mB19M3FNSZjhWmRsAPTUgwLgoId1hWh2yw+2SN/G 4a7w== X-Gm-Message-State: AOJu0YzvzDDZUVF1baLmDTMnhO2GDNzRgLnaGgkWiNU6Iu6WCGcuepnr 3emZLB7yNiQep7ORVFJoYMjGbXj40hQ59tiFNHo= X-Google-Smtp-Source: AGHT+IFVt6h1xx8QhAnKOYJT22MTC22jTJcpO/8UFLuSvs4pCYAnEt9V1db6EibCBwdS5R6EEpHOJDNcn5LTyLP1VYY= X-Received: by 2002:a05:600c:46cf:b0:40d:81c6:6fa6 with SMTP id q15-20020a05600c46cf00b0040d81c66fa6mr4029042wmo.146.1704294769637; Wed, 03 Jan 2024 07:12:49 -0800 (PST) MIME-Version: 1.0 References: <7b0a51d6-0d9d-7366-3a1a-f74397a02f55@dunslane.net> <253cef9e-1360-a1a6-5091-ad4368b1b8cc@dunslane.net> <58987a44-878a-338b-31de-4543c90604f1@dunslane.net> In-Reply-To: <58987a44-878a-338b-31de-4543c90604f1@dunslane.net> From: Robert Haas Date: Wed, 3 Jan 2024 10:12:37 -0500 Message-ID: Subject: Re: WIP Incremental JSON Parser To: Andrew Dunstan Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 3, 2024 at 9:59=E2=80=AFAM Andrew Dunstan = 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. --=20 Robert Haas EDB: http://www.enterprisedb.com