From: | Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>, Amit Langote <langote_amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Claudio Freire <klaussfreire(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: [HACKERS] Block level parallel vacuum |
Date: | 2020-01-16 12:55:05 |
Message-ID: | CANEvxPpK1Lf4HW0B-uJJ3KHmxkohod2es3pAKVVe_BtSB8jfUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
I would like to share my observation on this PG feature "Block-level
parallel vacuum".
I have tested the earlier patch (i.e v48) with below high-level test
scenarios, and those are working as expected.
- I have played around with these GUC parameters while testing
max_worker_processes
autovacuum = off
shared_buffers
max_parallel_workers
max_parallel_maintenance_workers
min_parallel_index_scan_size
vacuum_cost_limit
vacuum_cost_delay
- Tested the parallel vacuum with tables and Partition tables having
possible datatypes and Columns having various indexes(like btree, gist,
etc.) on part / full table.
- Tested the pgbench tables data with multiple indexes created manually
and ran script(vacuum_test.sql) with DMLs and VACUUM for multiple Clients,
Jobs, and Time as below.
./pgbench -c 8 -j 16 -T 900 postgres -f vacuum_test.sql
We observe the usage of parallel workers during VACUUM.
- Ran few isolation schedule test cases(in regression) with huge data
and indexes, perform DMLs -> VACUUM
- Tested with PARTITION TABLEs -> global/local indexes -> DMLs -> VACUUM
- Tested with PARTITION TABLE having different TABLESPACE in different
location -> global/local indexes -> DMLs -> VACUUM
- With Changing STORAGE options for columns(as PLAIN / EXTERNAL /
EXTENDED) -> DMLs -> VACUUM
- Create index with CONCURRENTLY option / Changing storage_parameter for
index as below -> DMLs -> VACUUM
with(buffering=auto) / with(buffering=on) / with(buffering=off) /
with(fillfactor=30);
- Tested with creating Simple and Partitioned tables -> DMLs ->
pg_dump/pg_restore/pg_upgrade -> VACUUM
Verified the data after restore / upgrade / VACUUM.
- Indexes on UUID-OSSP data -> DMLs -> pg_upgrade -> VACUUM
- Verified with various test scenarios for better performance of
parallel VACUUM as compared to Non-parallel VACUUM.
Time taken by VACUUM on PG HEAD+PATCH(with PARALLEL) < Time taken
by VACUUM on PG HEAD (without PARALLEL)
Machine configuration: (16 VCPUs / RAM: 16GB / Disk size: 640GB)
*PG HEAD:*
VACUUM tab1;
Time: 38915.384 ms (00:38.915)
Time: 48389.006 ms (00:48.389)
Time: 41324.223 ms (00:41.324)
*Time: 37640.874 ms (00:37.641) --median*
Time: 36897.325 ms (00:36.897)
Time: 36351.022 ms (00:36.351)
Time: 36198.890 ms (00:36.199)
*PG HEAD + v48 Patch:*
VACUUM tab1;
Time: 37051.589 ms (00:37.052)
*Time: 33647.459 ms (00:33.647) --median*
Time: 31580.894 ms (00:31.581)
Time: 34442.046 ms (00:34.442)
Time: 31335.960 ms (00:31.336)
Time: 34441.245 ms (00:34.441)
Time: 31159.639 ms (00:31.160)
--
With Regards,
Prabhat Kumar Sahu
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-01-16 12:56:38 | Re: remove some STATUS_* symbols |
Previous Message | Amit Kapila | 2020-01-16 12:04:38 | Re: [HACKERS] Block level parallel vacuum |