PgConf.Russia 2019

To migrate to a PostgreSQL/Postgres Pro we need multi-core servers to be carefully tuned for correct parallelism. What settings make multi-terabyte installations work fast and correctly?

We will share our PostgreSQL/Postgres Pro on BullSequana S and Bullion S servers testing experience.

The features of this hardware platform which are crucial for high-loaded configurations
• Multi-core Scale-up servers and PostgreSQL/Postgres Pro
• Results of stress testing of PostgreSQL/Postgres Pro running on the equipment.

You just set up your first PostgreSQL cluster, created a database schema, loaded some data, did some fine tuning of configuration. Now you want to make your cluster highly available. Unfortunately, PostgreSQL doesn't offer built-in automatic failover, but luckily for us, there are plenty of external tools for that. As a next logical step you start choosing a tool, and... you already doing it wrong, because first you have to define SLA, RTO, and RPO. In this talk I am going to cover most of the common mistakes people do when setting up a highly available cluster.

As is often seen in OLAP and batch processing workloads, the more complex a query (containing many joins, filters, aggregates), the more there is a possibility of row count estimation errors, which leads to planner choosing an inefficient execution plan.

To address that problem, I developed a tool called pg_plan_advsr as a PostgreSQL extension, which corrects the estimation errors by repeatedly feeding back the information collected during query execution to the planner.

The tool has three features:

1. Automatic plan tuning by repeatedly feeding execution information to planner
2. Preserve all plans generated during plan tuning in a history table
3. Create and store optimizer hints to be able to reproduce plans generated during tuning process

I verified the effectiveness of pg_plan_advsr by enabling it when running the join order benchmark (JOB) against PG 10.4 and observed its execution time shortening to 50% of the original. Therefore, it is useful for user who would like to do plan tuning for OLAP and batch processing.

I will talk about the following things in this presentation:

• Principles behind pg_plan_advsr and its architecture
• Detailed information about the measurements done with JOB
• Possible future enhancements
• Using aqo and pg_plan_advsr together (experimental)

The famous Russian PostgreSQL developer Oleg Bartunov will open the conference with his report on how and why PostgreSQL has turned from an open source university project into modern industrial grade database.