Re: Tracking of page changes for backup purposes. PTRACK [POC]
От | Robert Haas |
---|---|
Тема | Re: Tracking of page changes for backup purposes. PTRACK [POC] |
Дата | |
Msg-id | CA+TgmoZ95kKwpT+fXpx4imLGaCGB8jZs9pxuxCsqrwD1WayCtw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tracking of page changes for backup purposes. PTRACK [POC] (Aleksander Alekseev <a.alekseev@postgrespro.ru>) |
Ответы |
Re: Tracking of page changes for backup purposes. PTRACK [POC]
Re: Tracking of page changes for backup purposes. PTRACK [POC] |
Список | pgsql-hackers |
On Mon, Dec 18, 2017 at 8:34 AM, Aleksander Alekseev <a.alekseev@postgrespro.ru> wrote: > 10.1, without ptrack > > transaction type: <builtin: TPC-B (sort of)> > scaling factor: 1 > query mode: simple > number of clients: 4 > number of threads: 4 > duration: 300 s > number of transactions actually processed: 28622 > latency average = 41.928 ms > latency stddev = 18.238 ms > tps = 95.396155 (including connections establishing) > tps = 95.397406 (excluding connections establishing) > > > At first glance PTRACK doesn't seem to affect the overall performance > significantly. I think this doesn't really show much because it's apparently limited by the speed of fsync() on your filesystem. You might try running the test with synchronous_commit=off. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: