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
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 |