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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Дата
Msg-id 20220623140612.vwbt2pdyrawaqbpx@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Jelte Fennema <me@jeltef.nl>)
Ответы Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (John Naylor <john.naylor@enterprisedb.com>)
Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Jelte Fennema <me@jeltef.nl>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Use fadvise in wal replay