Re: Tracking of page changes for backup purposes. PTRACK [POC]
От | Aleksander Alekseev |
---|---|
Тема | Re: Tracking of page changes for backup purposes. PTRACK [POC] |
Дата | |
Msg-id | 20171218133430.GF30771@e733.localdomain обсуждение исходный текст |
Ответ на | Re: Tracking of page changes for backup purposes. PTRACK [POC] (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: Tracking of page changes for backup purposes. PTRACK [POC]
|
Список | pgsql-hackers |
Hello hackers, > I have two concerns about this: > 1. Does this affect the performance of the database when PTRACK is not enabled? > 2. What is the cost of having PTRACK enabled? I played with this patch a bit and did a simple benchmark on my laptop. Configuration: ``` make distclean && ./configure prefix=/some/path/ && make -s -j4 ``` postgresql.conf: ``` max_prepared_transactions = 100 wal_level = logical wal_keep_segments = 128 max_connections = 100 wal_log_hints = on max_wal_senders = 8 wal_keep_segments = 64 listen_addresses = '*' hot_standby = on log_statement = all max_locks_per_transaction = 256 shared_buffers = 1GB ``` The benchmark: ``` pgbench -i && pgbench -j 4 -c 4 -T 300 -P 10 ``` Here are the results. 10.1, ptrack_enable=false 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: 28772 latency average = 41.705 ms latency stddev = 18.274 ms tps = 95.895605 (including connections establishing) tps = 95.906434 (excluding connections establishing) 10.1, ptrack_enable=true scaling factor: 1 query mode: simple number of clients: 4 number of threads: 4 duration: 300 s number of transactions actually processed: 28607 latency average = 41.951 ms latency stddev = 18.454 ms tps = 95.344363 (including connections establishing) tps = 95.345290 (excluding connections establishing) 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. There are a few minor issues with the patch. There is a missing '/' symbol in the comment before ptrack_get_and_clear procedure: ``` * Get ptrack file as bytea and clear it */ bytea * ptrack_get_and_clear(Oid tablespace_oid, Oid table_oid) { ``` Also I believe the patch should include some changes of postgresql.conf.sample. I suggest to add this patch to the closest commitfest. Otherwise it can be lost. -- Best regards, Aleksander Alekseev
Вложения
В списке pgsql-hackers по дате отправления: