Message-ID: <8724f1d2-d11c-aaf2-2cd3-3725e9441d1e@dunslane.net>
Date: Wed, 6 Dec 2023 16:03:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>, Joe Conway <mail@joeconway.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 Davin Shearer <davin@apache.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: <cb1f118c-4698-4451-9ba9-dd8595f06c37@joeconway.com>
 <926ff917-8371-40ec-b5e6-ab7b0e09bdc5@joeconway.com>
 <315b81d4-4b67-7828-0355-3808cd14acd1@dunslane.net>
 <7a60faf6-e7f1-419d-aee6-10a78ea2fe81@joeconway.com>
 <2e7ff718-895d-83fc-46f7-be25e23b23b4@dunslane.net>
 <!bbf922c5-f571-483e-a2c6-2730b02183fe@joeconway.com>
 <1104915.1701877459@sss.pgh.pa.us>
 <19a5f9d8-bd1f-9!e51-0f5b-510c1189a8a7@dunslane.net>
 <1110690.1701880139@sss.pgh.pa.us> <20231206163349.GA2873889@nathanxps13>
 <20231206164439.GC2873889@nathanxps13>
 <77312d02-9325-4f14-9fe0-2746c2ee12bc@joeconway.com>
 <1136975.1701894046@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
Subject: Re: Emitting JSON to file using COPY TO
In-Reply-To: <1136975.1701894046@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/8724f1d2-d11c-aaf2-2cd3-3725e9441d1e%40dunslane.net>
Precedence: bulk


On 2023-12-06 We 15:20, Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
>> I'll see if I can add some caching to composite_to_json(), but based on
>> the relative data size it does not sound like there is much performance
>> left on the table to go after, no?
> If Nathan's perf results hold up elsewhere, it seems like some
> micro-optimization around the text-pushing (appendStringInfoString)
> might be more useful than caching.  The 7% spent in cache lookups
> could be worth going after later, but it's not the top of the list.
>
> The output size difference does say that maybe we should pay some
> attention to the nearby request to not always label every field.
> Perhaps there should be an option for each row to transform to
> a JSON array rather than an object?
>
> 			


I doubt it. People who want this are likely to want pretty much what 
this patch is providing, not something they would have to transform in 
order to get it. If they want space-efficient data they won't really be 
wanting JSON. Maybe they want Protocol Buffers or something in that vein.

I see there's  nearby proposal to make this area pluggable at 
<https://postgr.es/m/20231204.153548.2126325458835528809.kou@clear-code.com>


cheers


andrew

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