Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema <me@jeltef.nl>
Cc: Merlin Moncure <mmoncure@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, kevinvan@shift.com, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-06-23T14:06:12Z
Lists: pgsql-hackers
Hi, On 2022-06-23 13:33:24 +0200, Jelte Fennema wrote: > (reviving an old thread) > > On Thu, 23 Jun 2022 at 13:29, Merlin Moncure <mmoncure@gmail.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. It looks like there's quite a bit of low hanging fruits to optimize... > I'm pretty sure any semi-decent binary format would be able to outperform > this. Sure. It's a decent amount of work to define one though... It's clearly not acceptable to just dump out the internal representation, as already discussed in this thread. Greetings, Andres Freund
Commits
-
Build de-escaped JSON strings in larger chunks during lexing
- 3838fa269c15 16.0 landed