Re: Binary support for pgoutput plugin
Dave Cramer <davecramer@gmail.com>
From: Dave Cramer <davecramer@gmail.com>
To: David Fetter <david@fetter.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-06-04T19:47:04Z
Lists: pgsql-hackers
Dave Cramer On Mon, 3 Jun 2019 at 20:54, David Fetter <david@fetter.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
Commits
-
Weaken type-OID-matching checks in array_recv and record_recv.
- 670c0a1d474b 14.0 landed
-
Fix construction of updated-columns bitmap in logical replication.
- e8de627a3e05 11.9 landed
- d5daae47db5e 14.0 landed
- 71e561bd4bc2 12.4 landed
- 39d6aec1927c 10.14 landed
- 2f1f189cf880 13.0 landed
-
Allow logical replication to transfer data in binary format.
- 9de77b545313 14.0 landed
-
Phase 2 pgindent run for v12.
- 8255c7a5eeba 12.0 cited