Solving complex database problems by starting small
April 21–22
Over the years, I've been involved in some complicated performance optimization and corruption cases we discovered on our databases. When we talk about them, we usually focus on the cost and time optimization or how we managed to fix the entire corruption issue. But when I start a complicated investigation, I always remember the words of the first CTO I worked for: "How should it work in the most simple use case? How does it work for a single user, a single transaction, a single table, a single page of a table?" And only when you fully understand this simplified use case can you start building your problem case for this strong understanding of the basics.
And that is what I did over the years with PostgreSQL as well. A database with a single user table of just one page has been the foundation of my understanding of MVCC, vacuum, single page cleanup, FillFactor and Heap-Only Tuple (HOT) updates.
In this presentation, I will emphasize the usefulness of a single page table to build understanding and only build onward from that strong foundation. I will start briefly with the transaction IDs and vacuum, but quickly move on to a little more advanced topics such as differences between bloat and dead rows, FillFactor and HOT updates.
Every complicated topic starts with the most basic building blocks, and we talk too little about their importance. After this presentation, you will want to go back to simple use cases for all your complicated problems, if that wasn't your M.O. already.