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