Re: Binary support for pgoutput plugin

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Binary support for pgoutput plugin
Date: 2019-06-04 19:47:04
Message-ID: CADK3HHJ7_dfXzOLYLpdw8uNLcAWi0bzFCf3A0yiC5wShqAWphw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Cramer

On Mon, 3 Jun 2019 at 20:54, David Fetter <david(at)fetter(dot)org> wrote:

> On Mon, Jun 03, 2019 at 10:49:54AM -0400, Dave Cramer wrote:
> > Is there a reason why pgoutput sends data in text format? Seems to
> > me that sending data in binary would provide a considerable
> > performance improvement.
>
> Are you seeing something that suggests that the text output is taking
> a lot of time or other resources?
>
> Actually it's on the other end that there is improvement. Parsing text
takes much longer for almost everything except ironically text.

To be more transparent there is some desire to use pgoutput for something
other than logical replication. Change Data Capture clients such as
Debezium have a requirement for a stable plugin which is shipped with core
as this is always available in cloud providers offerings. There's no reason
that I am aware of that they cannot use pgoutput for this. There's also no
reason that I am aware that binary outputs can't be supported. The protocol
would have to change slightly and I am working on a POC patch.

Thing is they aren't all written in C so using binary does provide a pretty
substantial win on the decoding end.

Dave

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-04 20:07:17 Re: coverage additions
Previous Message Robert Haas 2019-06-04 19:15:47 Re: Avoiding hash join batch explosions with extreme skew and weird stats