| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Davin Shearer <davin(at)apache(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Emitting JSON to file using COPY TO |
| Date: | 2023-12-06 20:20:46 |
| Message-ID: | 1136975.1701894046@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Joe Conway <mail(at)joeconway(dot)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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2023-12-06 21:03:12 | Re: Emitting JSON to file using COPY TO |
| Previous Message | Joe Conway | 2023-12-06 19:48:52 | Re: Emitting JSON to file using COPY TO |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2023-12-06 20:43:37 | Re: gai_strerror() is not thread-safe on Windows |
| Previous Message | Peter Eisentraut | 2023-12-06 20:02:20 | automating RangeTblEntry node support |