Re: WIP Patch: Add a function that returns binary JSONB as a bytea

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

In response to

Responses

Browse pgsql-hackers by date

  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