Re: Improving replay of XLOG_BTREE_VACUUM records

Поиск
Список
Период
Сортировка
От Vladimir Borodin
Тема Re: Improving replay of XLOG_BTREE_VACUUM records
Дата
Msg-id B30A9718-AB30-465F-B4C9-6893BB12CDAC@simply.name
обсуждение исходный текст
Ответ на Re: Improving replay of XLOG_BTREE_VACUUM records  (David Steele <david@pgmasters.net>)
Список 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 по дате отправления:

Предыдущее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: dealing with extension dependencies that aren't quite 'e'
Следующее
От: Dmitry Ivanov
Дата:
Сообщение: Re: [PATCH] Phrase search ported to 9.6