PgConf.Russia 2019

This report focuses on the continuation of transferring our ECM “Priority” from MS SQL to Postgres. Technical solutions, issues of rewriting from T-SQL to plpgsql, optimization of the effective code and moving data will be covered. Additionally, there will be considered aspects of pgplsql performance testing to find the “bad code” of pgplsql as a candidate for optimization. The main objective of the presentation is to answer the question: "We have it in T-SQL - how to transfer it in PG?". The report is intended for junior Postgres developers and is a continuation of the previous report made at the conference in 2017(https://youtu.be/v6_4Szr8t14).

You just set up your first PostgreSQL cluster, created a database schema, loaded some data, did some fine tuning of configuration. Now you want to make your cluster highly available. Unfortunately, PostgreSQL doesn't offer built-in automatic failover, but luckily for us, there are plenty of external tools for that. As a next logical step you start choosing a tool, and... you already doing it wrong, because first you have to define SLA, RTO, and RPO. In this talk I am going to cover most of the common mistakes people do when setting up a highly available cluster.

Sometimes there is a great desire to return the database to the past, for a day or two or more days. The reasons are diverse, but most often one is to see what has changed. Or to see if the application behaved incorrectly after the update. Or it was just a command from the boss. The classic way everyone knows is to keep full backups and sets of WAL-logs to be able to recover to an arbitrary moment. This method is a real headache for DBAs/administrators, and it will not work quickly. Sure, there are some ways to optimize this process, but downtime is inevitable. PostgresPro offers a new way — database snapshots and the ability to return to them.

When you are optimizing Postgres it is usually maintenance that goes by the wayside. How do we fix autovacuum? Where did all of this bloat come from? Why am I getting IO spikes? How do I get RDS to behave?! Why are commits so slow on replication? The answer to all of these questions is understanding the relationship between proper Postgres maintenance and performance. Join us for a 3 hour jaunt through the wily world of making Postgres Go!