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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
