PgConf.Russia 2020

One of the most widespread branches of PostgreSQL distribution in Russia is 1C. In the report I would like to share thoughts about what is missing in PostgreSQL according to 1C

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.

Recently, I was working on a project where graphQL was used for sending requests to its .NET Core backend, but this was not a good idea. The point is, a graphQL query is a hierarchical structure with a dynamic set of fields. It’s difficult to perform such requests via a statically-typed programming language and a relational database as suggested by the tools available. So, I came up with the idea of using the plv8 extension and perform graphQL queries right on the database side. It took me about two hours to develop a working prototype that could perform the same queries as the software under development for more than one month! Then various improvements have been made and I want to introduce them all. If you are thinking of using graphQL instead of REST, my speech could be most useful and could help you to save a lot of time.

Porting applications from Oracle to Postgres is common work today. Unfortunately it is not without problems. In presentation I'll try to show the basic performance problems related to differences between Oracle and Postgres and PL/SQL and PL/pgSQL.