On 13/05/17 22:23, Andres Freund wrote: > On 2017-05-12 10:57:55 +0200, Petr Jelinek wrote: >> Hmm, well it helps but actually now that we don't track individual >> running transactions anymore it got much less effective (my version of >> 0005 does as well). >> >> The example workload I test with is: >> session 1: open transaction, do a write, keep it open >> session 2: pgbench -M simple -N -c 10 -P 1 -T 5 >> session 3: run CREATE_REPLICATION_SLOT LOGICAL in walsender >> session 2: pgbench -M simple -N -c 10 -P 1 -T 20 >> session 1: commit >> >> And wait for session 3 to finish slot creation, takes about 20 mins on >> my laptop without patches, minute and half with your patches for 0004 >> and 0005 (or with your 0004 and my 0005) and about 2s with my original >> 0004 and 0005. > > Is that with assertions enabled or not? With assertions all the time > post patches seems to be spent in some Asserts in reorderbuffer.c, > without it takes less than a second for me here. >
Right you are, I always forget to switch that off before benchmarks. > I'm appylying these now. Cool. Just for posterity, this also fixes the issue number 3 as the switch to consistent state is done purely based on xl_running_xacts and not decoded commits/aborts. So all done here, thanks! -- Petr Jelinek 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
