PGConf.SPB 2023

As you probably know, PostgreSQL has a number of distinct features compared to other DBMSs. For example, Postgres can process and store many different types of data. However, you need to know something about them before using them. In this talk, we will find the reason why queries to the table begin to slow down (and autovacuum / vacuum has nothing to do with it) and try to speed up such queries. I will tell you how integer data types work in PostgreSQL and touch on the topic of speeding up such queries. And finally, let's talk about how to make your data in tables take up less space while increasing the speed of queries to this data.

A story about practical approaches and tools for automating migration using 2 examples: a database with a structure change in the new version and a database with a significant content of the application's business logic.

During the years of its existence, Postgres Pro piled up a pool of problems when query execution was inappropriately slow or a query was too expensive to be executed, so it was never executed. Almost always in our practice, this was due to the choice of a non-optimal query plan. In our story, we will talk about a very unconventional attempt to solve this problem by re-planning queries. We will tell you what it is, how it works, who will find it helpful and the prospects for using this feature.

One of the requirements for the operation of the Corosync/Pacemaker failover cluster is the fencing of the failed node. In virtual environments, fencing is implemented by disabling the virtual machine through a hypervisor, in a cluster on physical servers - through IPMI/ILO. But what if it is impossible to organize fencing, for example, in the cloud environment? During this presentation, I will list and explain alternative methods of fencing a failed node.