Reduce the number of pallocs when building partition bounds
authorDavid Rowley <drowley@postgresql.org>
Tue, 6 Jul 2021 00:24:43 +0000 (12:24 +1200)
committerDavid Rowley <drowley@postgresql.org>
Tue, 6 Jul 2021 00:24:43 +0000 (12:24 +1200)
commit53d86957e980efa06f15232b8cff430d4cc6dd64
treedb322c36039feebc96d95e4324600ea2df9ae6cc
parent2aca19f2989aa938ece7306678f5494a984ece3f
Reduce the number of pallocs when building partition bounds

In each of the create_*_bound() functions for LIST, RANGE and HASH
partitioning, there were a large number of palloc calls which could be
reduced down to a much smaller number.

In each of these functions, an array was built so that we could qsort it
before making the PartitionBoundInfo. For LIST and HASH partitioning, an
array of pointers was allocated then each element was allocated within
that array.  Since the number of items of each dimension is known
beforehand, we can just allocate a single chunk of memory for this.

Similarly, with all partition strategies, we're able to reduce the number
of allocations to build the ->datums field.  This is an array of Datum
pointers, but there's no need for the Datums that each element points to
to be singly allocated.  One big chunk will do.  For RANGE partitioning,
the PartitionBoundInfo->kind field can get the same treatment.

We can apply the same optimizations to partition_bounds_copy().  Doing
this might have a small effect on cache performance when searching for the
correct partition during partition pruning or DML on a partitioned table.
However, that's likely to be small and this is mostly about reducing
palloc overhead.

Author: Nitin Jadhav, Justin Pryzby, David Rowley
Reviewed-by: Justin Pryzby, Zhihong Yu
Discussion: https://postgr.es/m/flat/CAMm1aWYFTqEio3bURzZh47jveiHRwgQTiSDvBORczNEz2duZ1Q@mail.gmail.com
src/backend/partitioning/partbounds.c