PgConf.Russia 2020

Postgres has always had strong support for relational storage. However, there are many cases where relational storage is either inefficient or overly restrictive. This talk shows the many ways that Postgres has expanded to support non-relational storage, specifically the ability to store and index multiple values, even unrelated ones, in a single database field. Such storage allows for greater efficiency and access simplicity, and can also avoid the negatives of entity-attribute-value (eav) storage. The talk will cover many examples of multiple-value-per-field storage, including arrays, range types, geometry, full text search, xml, json, and records.

It is our experience of the medical information system "RT MIS" transfer from MSSQL to PostgreSQL . When the necessity of transfer to PostgreSQL in our "RT MIS", one of the largest medical information systems, became imminent, we felt really terrified having assessed its amount: there was a huge number of stored procedures, functions, SQL-queries in its application code and services. It all requested transcribing, was exacerbated by demands on the system accessibility. So the variant "we awoke in the morning and PostgreSQL was working everywhere" was definitely impossible. That is why we chose another way: began eating "the elephant (PostgreSQL)" in chunks.

In my report, I am going to share our practical experience of the transfer, the instruments we used, the reason for another replication, the problems we met and their solutions. And finally, what turned out to be better: PostgreSQL or MSSQL.

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.

Tracking poor queries is an infinity quest for developers, who works with databases. Often we think that it is guilty the slow and big queries. But what to do if we do not have that kind of queries between backend and database? Which kind of queries should we looking for? What tools should be used for that work? This talk will cover all these questions.