title

text

October 25 – 26 , 2021

PGConf.Russia 2021

PGConf.Russia is a leading Russian PostgreSQL international conference, annually taking together more than 700 PostgreSQL professionals from Russia and other countries — core and software developers, DBAs and IT-managers. The 3-day program includes training workshops presented by leading PostgreSQL experts, more than 40 talks, panel discussions and a lightning talk session.

Thems

  • PostgreSQL at the cutting edge of technology: big data, internet of things, blockchain
  • New features in PostgreSQL and around: PostgreSQL ecosystem development
  • PostgreSQL in business software applications: system architecture, migration issues and operating experience
  • Integration of PostgreSQL to 1C, GIS and other software application systems.
  • more than
    0 participants
  • 0 speakers
  • 0
    minutes of conversation
  • 37 talks
  • hybrid
    format

Talks

Talks archive

PGConf.Russia 2021
  • Gregory Smolkin
    Gregory Smolkin PostgresPro

    PostgreSQL maintenance without backups is unacceptable. The constant growth of PostgreSQL clusters in maintenance creates new issues and bottlenecks for the chosen backup scenario. In this presentation, we will explain how to efficiently use pg_probackup under such circumstances.

  • Иван Чувашов
    Иван Чувашов Calltouch LLC.

    We maintain large PostgreSQL databases with the total data volume exceeding 180 TB. Every instance in the cluster gets a workload of 15 thousand requests per second. These circumstances certainly impose limitations on the classical approach to updating database structures. The cost of a DBA error gets higher, as even a small error can lead to a sleepless night) In my talk, I will cover our existing limitations for changes in the production environment, non-classical DBMS behavior under heavy workloads, and will discuss PostgreSQL in general.

  • Dmitry Vasilyev
    Dmitry Vasilyev PostgresPro

    In OZON, we work on PostgreSQL as a service. Currently, we have thousands of clusters. We know about the important questions software developers ask, and the most crucial ones are as follows: how to understand the database's workload and why this query is getting slow? In this presentation, I will explain how we help our developers answer these questions by simply having a look at our dashboard.

  • Oleg Bartunov
    Oleg Bartunov PostgresPro
    Nikita Glukhov
    Nikita Glukhov PostgresPro

    Finding the nearest neighbor can be required for various tasks. For example, when you need to find the closest object to a given point on the map. This task looks trivial to non-programmer (a person can easily cope with it if they have a map). In a software developer's reality, this task doesn't have a common solution available to everyone. To get rid of this headache, programmers often create ad hoc solutions also known as "crutches". These workarounds don't look nice and often ruin the mood of a creative programmer who needs to go to a beer pub to cope with the cognitive dissonance :)

    Indeed, while a person has a typical field of view and a map with a certain scale, the programmer has only one given point and a huge number of other points (i.e. billions of stars). This multitude of points gets a lot of incoming requests, including the write requests, not just read ones. You can write a perfect query in SQL, however, the real-world query execution plan will be depressingly long. To find the closest neighbor, you will have to read the entire table, compute all the distances from the given point and return the given number of good enough results. Indexing doesn't help in this case, as you will have to fully scan the search tree and read the entire table in random order. This will take much longer than simple table reading. In reality, tasks, where you need to efficiently find nearest neighbors, aren't limited to spatial search. It can also be used for classification tasks, finding typos, data clustering, and deduplication. All such tasks will benefit from efficient nearest neighbor search in DBMSs that are now a de facto standard for storing the data. What do we mean by "efficient search"? It means that our search is fast, concurrent, scalable, and supports various data types (most likely, non-standard ones). We implemented such KNN search in PostgreSQL 11 years ago. I will cover its implementation, today's state and share some use cases for KNN.

All talks

Partners

PGConf.Russia 2021

Organizational

Informational

Partner