PgConf.Russia 2019
PGConf.Russia is a leading Russian PostgreSQL international conference, annually taking together more than 500 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.
Talks
Talks archive
-
Александр Смолин Russian RailwaysVirtualization in companies has become an alternative to the conservative "one task-one server" approach, which allows efficient use of hardware resources, centralized management of server infrastructure, saving energy and cooling resources. The report explains how to configure the VMware environment for intensive input / output PostgreSQL and profiling tools virtual infrastructure to monitor performance and resolve identified problems.
-
Stepan Danilov RT LabsI would like to share my experience in optimization queries in PostgreSQL of RMIS (Regional Medical Information System).
-
Julien Rouhaud VMwareDeclarative partitioning was a long-awaited feature and has been enhanced since its introduction in PostgreSQL 10. However, for many users, finding optimal partitioning schemes to have the best benefits from partitioning is not an easy task. Therefore, we added in HypoPG a new hypothetical partitioning feature which helps users to design partitioning. In this presentation, I will provide a brief introduction of HypoPG and explain declarative partitioning, and then I'll show the usage of hypothetical partitioning feature and explain how the extension is working.
-
Nikolay Samokhvalov Nombox LLCShared_buffers = 25% – is it too much or not enough? Or it's the right value?
How can we ensure that this – pretty much outdated – recommendation suit well our needs?
It is time to start apply enterprise-level approach to tuning postgresql.conf. Not using various blind auto-tuners or advices from old articles and blog posts, but based on the following two aspects:
- comprehensive database experiments, conducted in automated fashion, repeated multiple times in conditions as close to production as possible, and
- deep understanding of DBMS and OS internals.
Using Nancy CLI (https://gitlab.com/postgres.ai/nancy) we will consider a concrete example: infamous shared_buffers, under various circumstances, in various projects. We will try to figure out, how to optimize this settings for given infrastructure, database, and workload.
Photos
Photo archive