Temporary tables as a legacy of the transition from MS SQL. Problems, optimization, approaches
Usage of temporary tables in PostgreSQL causes additional issues like high server resources consumption and low query performance. However, sometimes you need to rely on them especially when you need to migrate your code from MS SQL, and your initial code employed them, and you had some logic implemented at the database level. This talk covers issues related to usage of temporary tables when migrating from MS SQL, and the ways to resolve them using built-in PostgreSQL features based on the scenarios contained in the code.
Слайды
Жуковец.pptxВидео
Видео доступно участникам мероприятия, выполнившим вход в личный кабинет
Другие доклады
-
22 мин
Andrey Zelensky Береста РКReinforced backup methods for large Postgres Pro databases
The volume of data stored in Postgres Pro databases is growing rapidly. In some organizations, such databases have already exceeded tens of terabytes in size. The existing approaches to backups don't ensure timely backup and restore of data in such cases. We have supplemented the well-known and well-tested Postgres Pro backup tools with functionality that will allow users to backup and restore large databases. In addition to that, we have created our solution with the convenience of DBAs in mind.
-
45 мин
.jpg.180x180.jpg "Vadim Yatsenko")
Vadim Yatsenko Tantor LabHarmful advice on autovacuum you shouldn't ever follow
PostgreSQL has a number of peculiarities that you need to take into account not only while maintaining your database but also when designing your database schema. Experienced PostgreSQL are well aware of vacuuming process. On the web one can find tons of materials covering its internals, configurations and monitoring. Many valuable talks about vacuum were given at numerous conferences. However, we still face the common wraparound problem when the maximum possible number of transactions (xid) is reached. It happens even on databases that are relatively small in size. In my presentation, I will share a customer case that looks interesting to me. A chain of mistakes made at different stages of the database's life cycle once caused a disaster. The database fully stopped for one week, we detected a wraparound and spotted corrupted blocks. Maintenance was problematical, and we spent sleepless nights in search of a solution. We managed to achieve a local win as we finally restored the database, but it's not the end of this story, which makes it even more interesting.
-
22 мин
Andrey Borodin Яндекс
Aliaksandr Kalenik KonturHow we made GiST faster. What’s new in PostGIS 3.2?
I am going to explain a sorting method added in Postgres 14 that allows to create GiST index much faster. We'll also talk about the disadvantages of this sorting method discovered during implementation of its support in PostGIS and how it will be improved in the future. Also, new features and improvements included in PostGIS 3.2 will be reviewed.
-
45 мин
.JPG.180x180.jpg "Pavel Tolmachev")
Pavel Tolmachev Postgres ProfessionalCollapse in query plans. Achieve it and manage it
The more tables are involved with the query, the more difficult it is for the scheduler to choose a suitable execution plan (both time and memory usage increase). How can we "tell" the planner that it is better to connect this pair of tables first, and the rest can be connected later? What if we see that a part of our query can be improved, but the optimizer does not do this. In my presentation, I will talk about managing the order of connections. I will explain how we can influence the formation of a query plan using the standard "vanilla" PostgreSQL methods.