From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jelte Fennema <me(at)jeltef(dot)nl> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 14:06:12 |
Message-ID: | 20220623140612.vwbt2pdyrawaqbpx@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-06-23 14:06:40 | Re: Use fadvise in wal replay |
Previous Message | Robert Haas | 2022-06-23 13:58:07 | Re: Skipping logical replication transactions on subscriber side |