Performance tricks you have never seen before 2.0
summary
Loading heavy language extensions costs measurable time: PL/R first call ~220 ms, PostGIS ~10 ms, and preloading via session_preload_libraries turns that latency into predictable startup cost (1,000 connections × 8 MB = ~8 GB). Changing logging reduces WAL volume: a logical run produced ~10,035 MB vs wal_level minimal producing ~82 MB in the demo. Static datasets benefit from index fillfactor 100% to shrink indexes; default join_collapse_limit=8 drives planning work, and adjusting function costs cuts execution time ~20% by forcing a cheaper-first evaluation order.
AI-written summary · about
chapters (9)
- 0:00Introduction and motivation
- 2:20Connection process and preload libraries
- 7:46Session and shared preload libraries
- 13:01WAL size and transaction log impact
- 17:59Indexing and fillfactor tricks
- 23:02Join order and collapse limit
- 29:14Execution order and function cost
- 35:24Summary and hiring announcement
- 37:13Q&A session
related talks
26mPostgreSQL performance tips you have never seen before V2.0
41mUsing Databases to Pull Your Application Weight
25mPostgreSQL performance tips you have never seen before
16mExploring Query Optimization: How a few lines of code can save hours of time
40mPerformance is a feature: accelerating Postgres
56mLightning Talks- 16mExploring Query Optimization: How a few lines of code can save hours of time
01h 00m7 Tips to Performance Tuning, Optimization, and Everything