When ms matter: Maximizing query performance in CrateDB
summary
Shows concrete CrateDB tactics: use EXPLAIN/ANALYZE to inspect logical plans and see Lucene queries, prefer hash join over nested-loop when possible (linear complexity → big wins), choose sharding/partitioning so you hit few shards and aim for 10–50 GB per shard and roughly as many shards as CPU cores, prefer shard keys/cluster_by to avoid full scans, use Lucene indexes and avoid nulls (use ignore_null_value), and simple rewrites cut a 19s query to 200ms.
AI-written summary · about
chapters (11)
- 0:00Introduction and speaker background
- 1:04Distributed databases overview
- 3:32Common performance issues
- 5:58Understanding query execution
- 8:48Data distribution strategies
- 10:53Shard sizing and CPU cores
- 12:19Query optimization with sharding
- 14:28Lucene indexes and NULL handling
- 16:58Real-world query optimizations
- 17:19Community and resources
- 18:00Q&A session
related talks
38mAccelerating Query Performance in CrateDB
36mCrateDB: A Search Engine or a Database? Both! #bbuzz
41mMySQL Query Optimization Best Practices and Indexing
49mIt’s Not Always About the Index: The Hidden Secrets of Query Performance
30mCaching for Speed: Practical Performance Optimization in OpenSearch & Lucene
23mLessons from Optimizing Citus Queries at Heap
50mHow to choose the right index
40mMaking your elastic cluster perform