PGConf.Russia 2022

The more tables are involved with the query, the more difficult it is for the scheduler to choose a suitable execution plan (both time and memory usage increase). How can we "tell" the planner that it is better to connect this pair of tables first, and the rest can be connected later? What if we see that a part of our query can be improved, but the optimizer does not do this. In my presentation, I will talk about managing the order of connections. I will explain how we can influence the formation of a query plan using the standard "vanilla" PostgreSQL methods.

PostgreSQL has a number of peculiarities that you need to take into account not only while maintaining your database but also when designing your database schema. Experienced PostgreSQL are well aware of vacuuming process. On the web one can find tons of materials covering its internals, configurations and monitoring. Many valuable talks about vacuum were given at numerous conferences. However, we still face the common wraparound problem when the maximum possible number of transactions (xid) is reached. It happens even on databases that are relatively small in size. In my presentation, I will share a customer case that looks interesting to me. A chain of mistakes made at different stages of the database's life cycle once caused a disaster. The database fully stopped for one week, we detected a wraparound and spotted corrupted blocks. Maintenance was problematical, and we spent sleepless nights in search of a solution. We managed to achieve a local win as we finally restored the database, but it's not the end of this story, which makes it even more interesting.

In June 2020, AlfaStrakhovaniye was obliged to use RSA 2.0 government services along with other insurance companies. It was the only way to sell car insurance in Russia. AlfaStrakhovaniye is a leader in car insurance, and its applications degraded under the pressure of calls. It wasn't planned. Postgres used a huge amount of CPU and memory. Nobody could tell what was going on. Degradation started and stopped for no reason. Dev Team and Postgres Pro experts solved that problem. MyBatis in Java services was the killer. Our story is about the development of applications for heavy workloads and technical ignorance while using frameworks.

A book. Typically a reader sees only the final product, printed on paper or opened on a computer screen. In this talk I invite you to take a look at the dark side of my recently published “PostgreSQL Internals” book. Come if you are curious why the author would want to write scripts, modify the PostgreSQL source code, and program pictures.