Practical cases for query optimization in PostgreSQL

In my opinion, every DBA has to deal with "heavy" queries. The question is whether we can do something at all to speed up such query. Is it possible to optimize such queries, or maybe it doesn't make sense? For example, rewriting such query may take much longer than getting any performance gain from this rewritten query. During this talk, I'll tackle several approaches to speeding up queries, and demonstrate some practical examples of optimizations that I use at work.

Review of some historical CVEs

I'm not a real security expert. But this will help me to do ELI5 explanation of the funniest historical Postgres CVEs.

Tips and tricks for PostgreSQL operations for 1C

As we have large 1C+PostgreSQL database setups, questions often arise, the answers to which are not so easy to find even in the documentation. I would like to share my experience in solving such issues gained during several migrations of 1C from MS SQL to PostgreSQL made for clients from the RBC500 rating. This talk will cover the following points: How in-depth your statistics should be and why it can be dangerous? How can the creation of an explicit and implicit temporary table provoke the DBMS server downtime and how can we avoid it? In what case will the DBMS process be killed by the operating system due to overuse of RAM and what to do about it? Why having one database per cluster is good and why having multiple databases on one DBMS cluster is bad? If we are stick to the "1 cluster = 1 database" approach, what about server resources for test and development environments? Backups in PostgreSQL: what backup options we have

Five shades of sharding

The importance of sharding is now colossal. The size of today's databases exceeds 100 terabytes, scaling up vertically, and adding replicas containing a complete physical copy of the database is becoming difficult, especially when computational resources are scarce. Database sharding is a way to scale horizontally by partitioning data between compute nodes that are independent of each other.

In the PostgreSQL world, there are well-known scaling tools - CitusDB, and Greenplum - as well as new generation solutions - Cockroach DB, Yugabyte DB, SPQR, and Shardman.

In this talk, we will discuss the difference between these implementations, the advantages, and disadvantages of these solutions, examine the current state of implementation of sharding in vanilla PostgreSQL, and also touch on another important topic - providing data integrity and consistency guarantees across a distributed cluster.