PgConf.Russia 2020

We will discuss stored procedures and functions, as well as the code within the database in general. We'll take a look at stored procedures from different angles: as a DBA, a database developer, and a backend developer. We will try to understand the specifics of stored procedures that often go against the common coding guidelines, and discuss best practices for working with stored procedures.
This is mainly a motivational talk for database and backend developers, not an advanced tech talk.

You will have a fascinating journey through PostgreSQL settings. We will talk about that with 1C not so or on the contrary so that under it it is necessary to adjust specially DBMS. We will discuss approaches to testing the speed of 1C. Consider the various options for backup schemes and fault tolerance. In the process, we will compare the speed of 1C on PostgreSQL configured by default with the speed of 1C configured for PostgreSQL. Also, we will create a replica of PostgreSQL, and switch to it the 1C Server "live", see what users will see 1C during this operation. And a separate block will be devoted to Postgres Pro Enterprise Edition, how the use of its advantages affects the speed of 1C.

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.

Any DBA needs some kind of tool for historical workload analyse. Assume once at morning your monitoring team will report of sudden performance degradation at 2-3 a.m., and now you need to investigate this issue. What activities was most resource consuming within that hour? There are several tools for solving this problem, and I'll talk about one very easy and convenient tool - pg_profile. It need only a postgres database and a cron-like tool to run, and it will generate a workload profile report for your database as you need it. Ths report will be a good start point for further investigation.