From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: JSON output from psql |
Date: | 2020-05-13 21:01:18 |
Message-ID: | 5EBC601E.3020704@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/13/20 16:16, Gurjeet Singh wrote:
> On Wed, May 13, 2020 at 1:14 PM Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
>>
>> Arguably, delivering JSON (with its repeating attribute names in every
>> element of the array, dquotes and commas) is more network intensive
>> than converting the resultset to JSON on [client] side.
Does this suggest perhaps some sort of hybrid approach, where jsonbc
could be available as a binary on-the-wire format and the client only
needs the ability to deparse it: a query on the server could marshal
the results into that form, the client negotiates the binary transfer
format, and deparses to normal JSON syntax on its end?
It seems the server-side "compression" to jsonbc should be optimizable
when what is happening is marshaling of a tabular result: what the
repeating keys are going to be is known up front.
Maybe could use a transient (or session lifetime?) 'external' dictionary
that gets generated and sent to the client. but not stored in
pg_jsonb_dict?
Seems like a lot of work just to get json-shaped query results from psql,
but maybe the ability to receive jsonbc on the wire would be of interest
to drivers generally.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2020-05-13 21:17:42 | document? Re: Do I understand commit timestamps correctly? |
Previous Message | Laurenz Albe | 2020-05-13 20:36:40 | Re: COPY, lock release and MVCC |