PostgreSQL 12: A Few Special-Case Performance Enhancements

September 24, 2019
PostgreSQL 12: A Few Special-Case Performance Enhancements

With every new release of PostgreSQL, there are a range of performance enhancements. Some are system-wide and affect every user, but most are highly specific to a certain use case. In this post, I am going to briefly highlight three improvements in PG12 that speed up certain operations.

1. Minimal decompression of TOAST values

TOAST values are values that take up too much space to be stored conventionally within a record, so are stored out-of-line in a separate table-like structure on disk. By default, these large values are also compressed to save space.

There are cases where you don’t need the whole value, but only the bytes at the very front, such as:

  • The text functions substr() and starts_with()
  • The bounding box of a geometry type, which is used as an optimization for PostGIS point-in-polygon spatial joins

To use any portion of these values within a query in PG11 and earlier, the entire value is always decompressed first. This is a waste of CPU cycles. In PG12, we only decompress what we need, greatly speeding up accessing the beginning of a TOAST-ed value.

2. Faster float conversion to text

Previously, floating-point values were output by rounding to a specific number of digits, controlled by the configuration parameter extra_float_digits. This method is slow for output of large tables with many columns of real or double precision type.

In PG12, the decimal representation output is the shortest one that would be re-input as the exact original binary value. For example:

SET extra_float_digits = 3;
SELECT 0.3::double precision AS result;

In binary, 0.3 cannot be represented precisely. Previously, this would output as close to this imprecise binary value as possible:

        result
----------------------
 0.299999999999999989
(1 row)

In PG12, this outputs

 result
--------
    0.3
(1 row)

This representation is several times faster to generate. In this case, it also happens to match the original input, which is convenient.

3. Parallel query with SERIALIZABLE

The SERIALIZABLE isolation level is the strictest isolation level possible in PostgreSQL. We’ve had parallel query since PG9.6, but it was disallowed when SERIALIZABLE was specified. This is no longer the case, and now all isolation levels can take advantage of parallelism during query execution.

For more information on these, and many other improvements, see the PG12 release notes.

Share this

More Blogs