|
2 | 2 |
|
3 | 3 | ##Runtime overhead
|
4 | 4 |
|
5 |
| -First target was to measure`ptrack` overhead on TPS due to marking modified pages in the map in memory. We used PostgreSQL 12 cluster of approximately 1 GB size, initialized with`pgbench` on a`tmpfs` partition: |
| 5 | +First target was to measure`ptrack` overheadinfluenceon TPS due to marking modified pages in the map in memory. We used PostgreSQL 12 (REL_12_STABLE) cluster of approximately 1 GB size, initialized with`pgbench` on a`tmpfs` partition: |
6 | 6 |
|
7 | 7 | ```sh
|
8 | 8 | pgbench -i -s 133
|
@@ -55,9 +55,9 @@ Then a part of one relation was touched with a following query:
|
55 | 55 | UPDATE large_test2SET num3= num3+1WHERE num1<20000000/5;
|
56 | 56 | ```
|
57 | 57 |
|
58 |
| -After that, incremental`ptrack` backups were taken with`pg_probackup` followed by full backups. Tests show that`ptrack_backup_time / full_backup_time ~= ptrack_backup_size / full_backup_size`, i.e. iftheonly 20% of data were modified, then`ptrack` backup will be 5 times faster than full backup. Thus, the overhead of building`ptrack` map during backup is minimal. Example: |
| 58 | +After that, incremental`ptrack` backups were taken with`pg_probackup` followed by full backups. Tests show that`ptrack_backup_time / full_backup_time ~= ptrack_backup_size / full_backup_size`, i.e. if only 20% of data were modified, then`ptrack` backup will be 5 times faster than full backup. Thus, the overhead of building`ptrack` map during backup is minimal. Example: |
59 | 59 |
|
60 |
| -```log |
| 60 | +```sh |
61 | 61 | 21:02:43 postgres:~/dev/ptrack_test$time pg_probackup backup -B$(pwd)/backup --instance=node -p5432 -b ptrack --no-sync --stream
|
62 | 62 | INFO: Backup start, pg_probackup version: 2.3.1, instance: node, backup ID: QAA89O, backup mode: PTRACK, wal mode: STREAM, remote: false, compress-algorithm: none, compress-level: 1
|
63 | 63 | INFO: Parent backup: QAA7FL
|
|