Lukas Fittl

In this keynote, we'll take a look at 3 different paradigms of tuning Postgres: Tuning as a Human, Tuning with AI tools, and Tuning within Postgres itself. Having a Postgres expert tweak every single query and setting would be great, but most of us can't do it in practice.

PostgreSQL now runs everywhere, on-prem, cloud-managed, on Kubernetes. Each deployment model comes with its own monitoring stack, its own blind spots, and its own trade-offs.

Historically, Postgres has treated bad query plans as planner bugs to be reported and fixed, rather than teaching people to pin a particular plan. But even when a fix lands in a future release, a production system today is still suffering from the bad plan.

In this session I'll share an overview of my recent work to improve plan ID tracking in Postgres (similar to query ID tracking), and how it enables aggregate analysis of which query used which plan structure. We'll discuss which parts of a plan should be considered significant, and how to deal with special cases such as partitioning (which can lead to many unique plan IDs), and which parts of...

In the first half of this session, we will take a look at the recently released pg_stat_plans 2.0 extension, which functions similarly to pg_stat_statements, where it shows how often a query executes, but also captures how often a particular type of query plan got executed for a given query.

In this session we'll walk through best practices of optimizing a slow query in Postgres, and how we can have a better mental model for how Postgres plans out a query, be it join order, index usage, or planner costing - and getting a sense for knowing when it goes wrong.

In this talk, you will get an introduction to a new approach for automatically determining which set of indexes to create for a given Postgres query workload, based on objectives chosen by the developer or DBA.