Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Vladimir Borodin
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id B30A9718-AB30-465F-B4C9-6893BB12CDAC@simply.name
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (David Steele <david@pgmasters.net>)
List pgsql-hackers

25 марта 2016 г., в 19:11, David Steele <david@pgmasters.net> написал(а):

Hi Vladimir,

On 3/14/16 2:15 PM, Vladimir Borodin wrote:

JFYI, I’m preparing the stand to reproduce the initial problem and I
hope to finish testing this week.

Do you know when you'll have the results from the testing you were going to do?  It seems this patch is currently waiting on that to be finished.

I couldn’t reproduce the problem on pgbench database with scale factor 50000 last week. The test case was quite simple:
1. On master I was adding data to pgbench_accounts table.
2. On standby I was doing the following:
postgres@pgload01d ~ $ cat /tmp/query
\set naccounts 100000 * :scale
SELECT aid FROM pgbench_accounts WHERE aid = :naccounts;
postgres@pgload01d ~ $ /usr/pgsql-9.6/bin/pgbench -M prepared -f /tmp/query -c 1 -j 1 -T 3600 -P 10 -S -n pgbench
3. On master I was sometimes calling VACUUM pgbench_accounts.

Without applying patches there weren’t huge replication lags on standbys. Seems, that I'm doing something wrong… I’m doing my best right now to find the reason but I can’t give you any time evaluation :(


Thanks,
--
-David
david@pgmasters.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


--
May the force be with you…

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: dealing with extension dependencies that aren't quite 'e'
Next
From: Dmitry Ivanov
Date:
Subject: Re: [PATCH] Phrase search ported to 9.6