On 12 October 2017 at 16:09, Konstantin Knizhnik
<k.knizhnik@postgrespro.ru> wrote:
>
> Is the CREATE TABLE and INSERT done in the same transaction?
>
> No. Table was create in separate transaction.
> Moreover the same effect will take place if table is create before start of replication.
> The problem in this case seems to be caused by spilling decoded transaction to the file by
ReorderBufferSerializeTXN.
Yeah. That's known to perform sub-optimally, and it also uses way more
memory than it should.
Your design compounds that by spilling transactions it will then
discard, and doing so multiple times.
To make your design viable you likely need some kind of cache of
serialized reorder buffer transactions, where you don't rebuild one if
it's already been generated. And likely a fair bit of optimisation on
the serialisation.
Or you might want a table- and even a row-filter that can be run
during decoding, before appending to the ReorderBuffer, to let you
skip changes early. Right now this can only be done at the transaction
level, based on replication origin. Of course, if you do this you
can't do the caching thing.
> Unfortunately it is not quite clear how to make wal-sender smarter and let
> him skip transaction not affecting its publication.
You'd need more hooks to be implemented by the output plugin.
> I really not sure that it is possible to skip over WAL. But the particular problem with invalidation records etc can
besolved by always processing this records by WAl sender.
> I.e. if backend is inserting invalidation record or some other record which always should be processed by WAL sender,
itcan always promote LSN of this record to WAL sender.
> So WAl sender will skip only those WAl records which is safe to skip (insert/update/delete records not affecting this
publication).
That sounds like a giant layering violation too.
I suggest focusing on reducing the amount of work done when reading
WAL, not trying to jump over whole ranges of WAL.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers