Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aPIYv-0001HL-2d for pgsql-performance@arkaria.postgresql.org; Fri, 29 Jan 2016 23:34:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aPIYu-0002qo-FM for pgsql-performance@arkaria.postgresql.org; Fri, 29 Jan 2016 23:34:44 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aPIYt-0002og-HR for pgsql-performance@postgresql.org; Fri, 29 Jan 2016 23:34:43 +0000 Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aPIYq-0006Sg-Pe for pgsql-performance@postgresql.org; Fri, 29 Jan 2016 23:34:42 +0000 Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id A7389A80AA; Sat, 30 Jan 2016 00:34:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id F4cegAEpRCpB; Sat, 30 Jan 2016 00:34:36 +0100 (CET) X-Originating-IP: 98.122.164.227 Received: from [192.168.10.146] (unknown [98.122.164.227]) (Authenticated sender: adsend@dunslane.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 7779BA809B; Sat, 30 Jan 2016 00:34:35 +0100 (CET) Subject: Re: jsonb_agg performance To: jfleming@kispring.com, pgsql-performance@postgresql.org References: From: Andrew Dunstan Message-ID: <56ABF70A.1020405@dunslane.net> Date: Fri, 29 Jan 2016 18:34:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On 01/29/2016 05:06 PM, jfleming@kispring.com wrote: > The jsonb_agg function seems to have significantly worse performance > than its json_agg counterpart: > > => explain analyze select pa.product_id, jsonb_agg(attributes) from > product_attributes2 pa group by pa.product_id; > QUERY PLAN > -------------------------------------------------------------------------------------------------------------------------------------- > GroupAggregate (cost=1127.54..1231.62 rows=3046 width=380) (actual > time=28.632..241.647 rows=3046 loops=1) > Group Key: product_id > -> Sort (cost=1127.54..1149.54 rows=8800 width=380) (actual > time=28.526..32.826 rows=8800 loops=1) > Sort Key: product_id > Sort Method: external sort Disk: 3360kB > -> Seq Scan on product_attributes2 pa (cost=0.00..551.00 > rows=8800 width=380) (actual time=0.010..7.231 rows=8800 loops=1) > Planning time: 0.376 ms > Execution time: 242.963 ms > (8 rows) > > => explain analyze select pa.product_id, json_agg(attributes) from > product_attributes3 pa group by pa.product_id; > QUERY PLAN > -------------------------------------------------------------------------------------------------------------------------------------- > GroupAggregate (cost=1136.54..1240.62 rows=3046 width=387) (actual > time=17.731..30.126 rows=3046 loops=1) > Group Key: product_id > -> Sort (cost=1136.54..1158.54 rows=8800 width=387) (actual > time=17.707..20.705 rows=8800 loops=1) > Sort Key: product_id > Sort Method: external sort Disk: 3416kB > -> Seq Scan on product_attributes3 pa (cost=0.00..560.00 > rows=8800 width=387) (actual time=0.006..5.568 rows=8800 loops=1) > Planning time: 0.181 ms > Execution time: 31.276 ms > (8 rows) > > The only difference between the two tables is the type of the > attributes column (jsonb vs json). Each table contains the same 8800 > rows. Even running json_agg on the jsonb column seems to be faster: > > => explain analyze select pa.product_id, json_agg(attributes) from > product_attributes2 pa group by pa.product_id; > QUERY PLAN > -------------------------------------------------------------------------------------------------------------------------------------- > GroupAggregate (cost=1127.54..1231.62 rows=3046 width=380) (actual > time=30.626..62.943 rows=3046 loops=1) > Group Key: product_id > -> Sort (cost=1127.54..1149.54 rows=8800 width=380) (actual > time=30.590..34.157 rows=8800 loops=1) > Sort Key: product_id > Sort Method: external sort Disk: 3360kB > -> Seq Scan on product_attributes2 pa (cost=000..551.00 > rows=8800 width=380) (actual time=0.014..7.388 rows=8800 loops=1) > Planning time: 0.142 ms > Execution time: 64.504 ms > (8 rows) > > Is it expected that jsonb_agg performance would be that much worse > than json_agg? I do expect it to be significantly worse. Constructing jsonb is quite a lot more expensive than constructing json, it's the later processing that provides the performance benefit of jsonb. For 99 out of 100 uses that I have seen there is no need to be using jsonb_agg, since the output is almost always fed straight back to the client, not stored or processed further in the database. Rendering json to the client is extremely cheap, since it's already just text. Rendering jsonb as text to the client involves a lot more processing. cheers andrew -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance