Overhead of pg_stat_statements | Scaling Postgres 304

Рет қаралды 668

Күн бұрын

To get the show notes as well as get notified of new episodes, visit:
www.scalingpostgres.com/episo...
In this episode of Scaling Postgres, we discuss the overhead of using pg_stat_statements, DBA use of logs, an RDS migration success, and some Postgres best practices.
Want to learn more about Postgres performance?
Join my FREE mini-course called the PostgreSQL Performance Starter Kit here: www.scalingpostgres.com/cours...
Timestamps:
00:00 - Intro
00:24 - Overhead of pg_stat_statements and pg_stat_kcache
03:55 - Logging: What, Why and When
06:40 - A story of a spectacular success - Intro to AWS RDS database migration series
08:23 - FOSSCOMM 2023 Heraklion - How PostgreSQL can help you enforce best practices
09:06 - SQL Optimization: a comprehensive developer’s guide
09:39 - Last Updated Columns With Postgres
10:35 - Moving local settings for pg_hba.conf and postgresql.conf out of PGDATA
11:25 - An Efficient Way to Check for Existence of Multiple Values in SQL
12:14 - Out of range planner statistics and "get_actual_variable_range" in Postgres
13:12 - RFC: Extension Metadata Typology
13:41 - Outro
#postgres #postgresql

Пікірлер: 4

@jaimeduncan6167 5 ай бұрын

Yes, I used the logs often. And I agree that logging all the statements is crazy. I do log long-running queries.

@ordinarygg 4 ай бұрын

7:40 Those guys just getting started to discover what "code" refactoring is capable of doing with infrastructure and how it impacts the whole ecosystem. The most efficient applications could run on our own cpu and distributed across a lot of servers without k8s and docker. It requires policies and agreements that a lot of companies are bad( And to cover this they use engineering as an excuse so to maintain all complexity you need even more complexity.