Performance

When investigating PostgreSQL performance, the usual starting point is pg_stat_statements. From there, many teams sort queries by mean_exec_time or total_exec_time and start optimizing the first rows in the list. That approach is simple, but it often leads to the wrong priorities. A query that takes five seconds but runs twice a day is not necessarily more important than a query that takes five milliseconds and runs millions of times. Conversely, a query with a high total execution time may simply be a normal core workload query, not necessarily the best optimization target. ...

PostgreSQL index design is often misunderstood. Many developers think that creating a good index simply means: “Create an index containing the columns from the WHERE clause.” In reality, efficient index design is far more nuanced. The order of columns inside a composite index matters enormously, and the best choice depends on: Predicate types (=, >=, BETWEEN, LIKE, etc.) Column selectivity Table size PostgreSQL planner statistics Actual execution plans This article explains the core principles behind efficient PostgreSQL index design before showing how pgAssistant automates this process using execution plans and database statistics. ...

Detecting PostgreSQL optimization issues with deterministic analysis For years, I kept seeing the same PostgreSQL problems in production: missing foreign key indexes stale statistics unused indexes datatype mismatches sequences approaching exhaustion postgres configuration Most of these issues are not difficult to detect. They already exist inside PostgreSQL catalogs, statistics, … The difficult part is usually connecting the signals together and understanding their operational impact. For the past months, I have been working on a deterministic PostgreSQL analysis approach inside pgAssistant 2.8. ...