PGConf.Russia 2025

A brief presentation on various extensions that can assist with optimization.

This talk will likely be of interest to network providers who can enhance their cool features by adding something to the syntax to simplify administration, as well as anyone interested in machine learning. We will explore the SQL parsing mechanism, what, where, and how to modify it in order to introduce new syntax constructs. Additionally, I will demonstrate the capabilities of machine learning on tabular data, all within the database, using the new syntax.

I’ll talk about the challenges you’ll face if you decide to implement a new TableAM. What to choose: Generic XLog or Custom RMGR? Why use a Custom SMGR? How to integrate PostgreSQL allocators into third-party libraries, even if they don't officially support it? What’s missing for a columnar engine (including vectorization and late materialization), and how can we work around those limitations?

In the second part, I’ll dive into the internals of pgpro_tam — a new native table engine for OLAP that supports standard data formats, various SMGRs, and, if needed, third-party schedulers and execution engines, all while adhering to ACID principles. This is designed to achieve the fastest analytics on PostgreSQL (not just plugging in DuckDB).

Where I used to work, we had pushed ElasticSearch to its breaking point. We needed an even more scalable replacement for a write-heavy, read-seldom workload. So we built one on PostgreSQL. Now, many of us are building the successor as an open source project. 

This talk goes over the design of Bagger (named after the giant mining machines), which can manage logs into tens or hundreds of petabytes. More than just a review of the architecture, this talk focuses on the whys and the tradeoffs made in the design. 

The talk is intended both to showcase how programmable and powerful PostgreSQL is, but also illustrate the fundamental tradeoffs which must be faced when pushing any technology into the big data space.