Debate: Autotuning
summary
Autotuning promises saves DBAs hours by measuring KPIs like per-query response time and memory ceilings and using domain-specific models to adjust Postgres settings; vendors (DBTune, EDB) show automated workflows that roll changes and validate improvements via monitoring. Opposing points cite LLMs are probabilistic, adaptive optimizers (Oracle) being disabled for performance, inability to see OS/storage/network context, onboarding and extra-agent overhead, and risk of over-tuning that regresses day-to-day stability. The conclusion: automate measured, reversible changes now, defer risky runtime plan changes.
AI-written summary · about
chapters (5)
- 0:00Debate introduction
- 3:32Arguments against autotuning
- 7:47Arguments for autotuning
- 12:23Stability vs surprises debate
- 17:42Audience reaction and consensus
related talks
48mDBtune: AI-driven performance tuning for all PostgreSQL flavors
18mWhy Postgres Is Better Than MySQL for Automated Knob Tuning
28mAutotuning PostgreSQL on Azure Flexible Server
27mBuilding safety tooling for risk-free AI tuning of Postgres
04mPostgres Tuning is saved by Sovenath Shaw
48mChatGPT Ain’t Got $%@& On Me! Next Generation Automated Database Tuning
34mDo we really need a DBA to manage our PostgreSQL databases on DBaaS
53mMake Your Database Dream of Electric Sheep: Designing for Autonomous Operation