Re: Recovery performance of DROP DATABASE with many tablespaces

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Recovery performance of DROP DATABASE with many tablespaces
Дата
Msg-id 20180710060405.GI1661@paquier.xyz
обсуждение исходный текст
Ответ на Re: Recovery performance of DROP DATABASE with many tablespaces  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Recovery performance of DROP DATABASE with many tablespaces  (Michael Paquier <michael@paquier.xyz>)
Re: Recovery performance of DROP DATABASE with many tablespaces  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> TBH, I have no numbers measured by the test.
> One question about your test is; how did you measure the *recovery time*
> of DROP DATABASE? Since it's *recovery* performance, basically it's not easy
> to measure that.

It would be simple to measure the time it takes to replay this single
DROP DATABASE record by putting two gettimeofday() calls or such things
and then take the time difference.  There are many methods that you
could use here, and I suppose that with a shared buffer setting of a
couple of GBs of shared buffers you would see a measurable difference
with a dozen of tablespaces or so.  You could also take a base backup
after creating all the tablespaces, connect the standby and then drop
the database on the primary to see the actual time it takes.  Your patch
looks logically correct to me because DropDatabaseBuffers is a
*bottleneck* with large shared_buffers, and it would be nice to see
numbers.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Usage of epoch in txid_current
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Let's remove DSM_IMPL_NONE.