| From: | Jelte Fennema <me(at)jeltef(dot)nl> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, kevinvan(at)shift(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |
| Date: | 2022-06-23 11:33:24 |
| Message-ID: | CAGECzQQuXbies_nKgSiYifZUjBk6nOf2=TSXqRjj2BhUh8CTeA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(reviving an old thread)
On Thu, 23 Jun 2022 at 13:29, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> I'll still stand other point I made though; I'd
> really want to see some benchmarks demonstrating benefit over
> competing approaches that work over the current formats. That should
> frame the argument as to whether this is a good idea.
I tried to use COPY BINARY to copy data recently from one Postgres
server to another and it was much slower than I expected. The backend
process on the receiving side was using close to 100% of a CPU core.
So the COPY command was clearly CPU bound in this case. After doing a
profile it became clear that 50% of the CPU time was spent on parsing
JSON. This seems extremely excessive to me. I'm pretty sure any
semi-decent binary format would be able to outperform this.
FYI: The table being copied contained large JSONB blobs in one of the
columns. These blobs were around 15kB for each row.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikita Malakhov | 2022-06-23 11:46:07 | Re: Pluggable toaster |
| Previous Message | houzj.fnst@fujitsu.com | 2022-06-23 11:28:32 | Fix instability in subscription regression test |