Understanding new storage-related features

Let's now turn our attention to one of the biggest achievements (in my judgment) of the past 10 years in the PostgreSQL universe: pluggable storage engines. What is the general problem? For the past, roughly, 30 years, the PostgreSQL community has focused its attention and development efforts on one single storage engine, the heap. While a general-purpose storage engine performs well in many cases, some situations demand different approaches to storage. This is especially true if you are running analytics or high volumes of UPDATE statements changing millions or even billions of rows, given an OLTP workload.

So, what is the problem with a conventional row store? Suppose you are running analytics on a large table. Your table might consist of dozens of columns and you have got to read them all to retrieve just a handful of columns. Of course, this is inefficient. By storing data in a column-oriented way, you have only got to fetch the data you really needed. But there is more to this: the content of a column contains a lot more redundancy than a row. id, name, date is definitely less redundant than name, name, name.

In short, you can apply a lot more optimizations for certain workloads. However, this is not true for all kinds of applications. A classical row store is king if you are running classical OLTP operations or if you tend to need the entire row anyway.

The bottom line is: PostgreSQL 12 offers great opportunities for future developments and will lead the way for an explosion of storage engines.