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
-
Sergey Andreev Ortikon GroupSeveral real cases from those who stopped the migration to PostgreSQL.
-
Joshua Drake Command Prompt, Inc.One of the most soft after features of Postgres v10 is logical replication. In this presentation we will cover what Logical Replication is, how it compares to Binary (Streaming Replication), how Logical Replication works, configuring Logical Replication, Logical Replication limitations, gotchas, security and management. We will also discuss potential deployed architectures with Logical and Binary Replication and some neat features of the underlying technology.
At the end of this presentation an attendee with a reasonable understanding of how to manage Postgres will be able to configure Logical replication for use.
-
Joshua Drake Command Prompt, Inc.
When you are optimizing Postgres it is usually maintenance that goes by the wayside. How do we fix autovacuum? Where did all of this bloat come from? Why am I getting IO spikes? How do I get RDS to behave?! Why are commits so slow on replication? The answer to all of these questions is understanding the relationship between proper Postgres maintenance and performance. Join us for a 3 hour jaunt through the wily world of making Postgres Go!
-
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