Re: logical changeset generation v4 - Heikki's thoughts about the patch state

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Phil Sorber <phil(at)omniti(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical changeset generation v4 - Heikki's thoughts about the patch state
Date: 2013-01-28 09:59:52
Message-ID: 51064C18.8020104@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24.01.2013 00:30, Andres Freund wrote:
> Also, while the apply side surely isn't benchmarkable without any being
> submitted, the changeset generation can very well be benchmarked.
>
> A very, very adhoc benchmark:
> -c max_wal_senders=10
> -c max_logical_slots=10 --disabled for anything but logical
> -c wal_level=logical --hot_standby for anything but logical
> -c checkpoint_segments=100
> -c log_checkpoints=on
> -c shared_buffers=512MB
> -c autovacuum=on
> -c log_min_messages=notice
> -c log_line_prefix='[%p %t] '
> -c wal_keep_segments=100
> -c fsync=off
> -c synchronous_commit=off
>
> pgbench -p 5440 -h /tmp -n -M prepared -c 16 -j 16 -T 30
>
> pgbench upstream:
> tps: 22275.941409
> space overhead: 0%
> pgbench logical-submitted
> tps: 16274.603046
> space overhead: 2.1%
> pgbench logical-HEAD (will submit updated version tomorrow or so):
> tps: 20853.341551
> space overhead: 2.3%
> pgbench single plpgsql trigger (INSERT INTO log(data) VALUES(NEW::text))
> tps: 14101.349535
> space overhead: 369%
>
> Note that in the single trigger case nobody consumed the queue while the
> logical version streamed the changes out and stored them to disk.

That makes the space overhead comparison completely worthless, no? I
would expect the trigger-based approach to generate roughly 100% more
WAL, not close to 400%. As long as the queue is drained constantly,
there should be no big difference in the disk space used, except for the
WAL.

> Adding a default NOW() or similar to the tables immediately makes
> logical decoding faster by a factor of about 3 in comparison to the
> above trivial trigger.

Hmm, is that because of the conversion to text? I believe slony also
converts all the values to text in the trigger, because that's simple
and flexible, but if we're trying to compare the performance of logical
changeset generation vs. trigger-based replication in general, we should
choose the most efficient trigger-based scheme to compare with. That
means, don't convert to text. And write the trigger in C.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-28 10:39:16 Re: Support for REINDEX CONCURRENTLY
Previous Message Magnus Hagander 2013-01-28 09:45:10 Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown