Transaction Isolation Levels in PostgreSQL

Everyone has heard something about transaction isolation levels, but oddly enough, almost no one can clearly explain what it is any why it is important. At the same time, for many operations, it is critical to have a clear understanding of isolation levels and how they can affect the result. Indeed, if a customer has been paid twice and the developer has to pay back the losses, it won't seem unimportant. We'll discuss how to avoid such unpleasant situations.

Tool as code: testing Postgres

At the master class, we will learn how to execute fast load tests of Postgres databases: optimizing database configurations, data structure, indexes, OS settings, etc. To do this, we will create a code, build the infrastructure for the test from it and will do the test. As a result, we get a flexible tool in the code to which you can attach any monitoring, and for which you don't have to pay a lot of money, because the environment is created in 7 minutes in an empty AWS account and destroyed after test

Hardware acceleration options for Postgres: Intel Optane DC Persistent Memory and FPGA.

If you care about Postgres performance, there are a number of hardware acceleration options to help with different use cases. Intel Optane DC persistent memory creates new tier in data hierarchy allowing developers to utilize performance of traditional memory combining with volume and persistency of block storage devices. Unlike traditional DRAM-only in-memory systems, where memory is small, expensive, and volatile, Intel Optane DC persistent memory makes it possible to run larger Postgres databases (terabytes) in memory for higher performance. FPGAs are integrated circuits that can be reprogrammed dynamically to accelerate a specific workload such as SQL execution and data compression. FPGA accelerators extend Postgres with hundreds of SQL reader and writer processes that work in parallel on the FPGA. It’s similar to adding hundreds new cores to boost parallel processing on your server.

Writing a User-defined datatype

Walk-through of extending PostgreSQL with a user-defined type. The journey begins from the basics, from creating simple domain types over existing types, and continues to implementing a full-blown datatype from scratch in C.

PostgreSQL's advanced index types, GiST, GIN, and SP-GiST, are covered in enough detail to give an understanding of what each of them is good for. Support functions for each of them are shown for the example 'color' datatype.