Feed: Planet PostgreSQL.
Partitioning introduced in PostgreSQL 10 increases performance in certain scenarios. In PostgreSQL 13, pgbench was extended to run benchmark tests for range and hash partitions by partitioning the pgbench_accounts table according to the parameters provided. Since pgbench_accounts is the largest table, the bulkload command COPY is used to populate it and pgbench logs the time taken to insert in that table. This blog will explore how this operation is affected by table partitioning.
Tests were performed for partition counts 200, 400, 600 and 800 on pgbench scales varying from 500 (5 GB) to 5000 (50GB) for both the range and hash partition type with the following settings:
- pgbench thread/client count = 32
- shared_buffers = 32GB
- min_wal_size = 15GB
- max_wal_size = 20GB
- checkpoint_timeout=900
- maintenance_work_mem=1GB
- checkpoint_completion_target=0.9
- synchronous_commit=on
The hardware specification of the machine on which the benchmarking was performed is as follows:
- IBM POWER8 Server
- Red Hat Enterprise Linux Server release 7.1 (Maipo) (with kernel Linux 3.10.0-229.14.1.ael7b.ppc64le)
- 491GB RAM
- IBM,8286-42A CPUs (24 cores, 192 with HT)
Range Partitions
The red dotted lines show the performance for an unpartitioned table across different data sizes. It is evident that the range partitioned table takes slightly longer time but increasing the partition count hardly influences the load time.
Hash Partitions
The amount of time taken by a hash partitioned table with the lowest partition count for lowest data size (200 parts, 5GB) is 60% more than that of the unpartitioned table and the time taken for the hash partitioned table with the highest partition count and largest size (800 parts, 50 GB) is 180% more than that of the unpartitioned table. It is obvious that the number of partitions has heavily impacted the load time.
Combination graphs
Here are a few graphs that merge the results of the two partition types, range, and hash, to distinctly show the difference between the two types.
The above graph displays how the range and the hash partitioned table with 400 partitions compare against a non-partitioned one for different data sizes. There is a general upward trend as the data size to be loaded increases in all cases which are expected- larger the data, the longer the time taken. The range-partitioned table takes about 20-25% more time than the unpartitioned table and the hash partition shows a steep substantial increase in load time as the data size increases.
This graph presents how the range and hash partitioned table compare against a non-partitioned one for different partition counts at a data size of 50 GB. Here again, the range partition shows a steady 20-25% increase but the hash partitioned table exhibits a more dramatic change as the partition count increases.
Explaining the behavior
Though there is an expected influence of size on the load time, the hash partitioned table is also profoundly impacted by the amount of partitions the table has.
To decipher this, let us look at how pgbench partitions and inserts data into the table. The pgbench_accounts table is partitioned on the column aid which is called the partition key and a series of data for aid values are generated in sequence from 1 to pgbench_scale * 100000 and inserted using the COPY command. In COPY the tuple routing parameters are set for the partitioned table and then the data is inserted. The range-partitioned table splits data based on the data value such that each partition can hold all tuples with aid values that fall within the range and hash partitioned table uses a modulo operator on the value being inserted and the remainder obtained by performing the operation is used to determine the partition into which the value will be inserted.
Since pgbench copies data ordered according to the partition key viz aid, the range partition insertion behavior shows an ideal case where data of one partition is fully inserted before moving on to the next partition. For the hash partitioned table, the first value is inserted in the first partition, the second value in the second partition and so on until all the partitions are covered before it loops from the first partition again until all the data is exhausted exhibiting the worst-case scenario where the partition is repeatedly switched for every value inserted. As a result, the amount of times the partition is switched in a range-partitioned table is equal to the number of partitions which in this test case is not more than 800 while in hash the amount of times the partition has switched is equal to the amount of data being inserted which is more than 5 lakh times. This causes a massive difference in timing for the two partition types.
Conclusion
When using COPY for data ordered on the partition key column, no matter the size or the number of partitions, the operation would take about 20-25% more time than an unpartitioned table. If the data being copied is unordered with respect to the partition key then the time taken will depend on how often the partition has to be switched between insertions.
Hence, to speed up bulk-load COPY operation, it is advisable to have data sorted according to the partition key of the table so that there is minimal partition switching ensuring lower operation time.