PgConf.Russia 2020

I will share our experience of migrating a server application for Russian railways from Oracle 11g Standard Edition to vanilla PostgreSQL 11.5.
At the time of migration, the database contained about 200 stored procedures of over 60000 lines of Oracle PL/SQL code (which has been developed since 2006, that is, for more than 12 years), about 250 tables, and 50GB of data.
Starting with a prologue, we'll describe our adventures along the migration process, as well as pleasant and unpleasant surprises we encountered, and finally get to an epilogue and a happy end. The story is told on behalf of an Oracle user exploring Postgres.

We would like to share our test results (including performance testing) of PostgreSQL/Citrus and MongoDB for our company's data. It has been a very exciting process with unexpected turns and a somewhat controversial outcome.

pg_repack is one of the most popular instruments for removing bloat of tables and indexes in Postgres. In most cases, it works perfectly. But if you use such a feature of Postgres as deferred constraints, using pg_repack becomes more difficult or even impossible. I will talk about how we encountered the problem and will describe some workarounds - from internal instruments of Postgres to a small patch for pg_repack.

Last year I made a talk about unexpected PostgreSQL bottlenecks, which could make sad surprise to user (or DBA). Feedback to my talk was very positive. Additionally I have new material after year. This is why I'm making a sequel including new unexpected situations when your database hangs. This time focus will be on multicore hardware platforms, but not only them.