Milos Radivojevic
where else to find them
no profile links on file
what they talk about
where they keep going back
- SQLBits3 editions2019–2024
on a stage with
never shared a talk
who talks about the same things
- Monica Rathbun11 talks
- Bradley Ball7 talks
- CLÁUDIO SILVA9 talks
- John Morehouse14 talks
- Dimitri Furman5 talks
- Ajay Jagannathan11 talks
| title | conference | date |
|---|---|---|
| When to stop tuning a query | SQLBits 2024 | 2024-03-19 |
A single T‑SQL query against 100M/335M rows is tuned stepwise: forcing a nested loop join cuts elapsed time from ~11s to ~2s but exposes a 10 GB memory grant… | ||
| Dealing with Very Large Tables in SQL Server | SQLBits 2024 | 2024-03-19 |
Shows a real 20 billion–row / 4.6 TB table that takes 28 minutes and ~72 million logical reads to return 3 rows when missing an index, so adding indexes must… | ||
| Dealing with Very Large Tables in SQL Server | SQLBits 2022 | 2022-03-08 |
Practical runbook for tables >1TB with concrete numbers and fixes: an unindexed filter on 20 billion rows, 4.6 TB, 28 minutes, 72M logical reads shows why… | ||
| When to stop tuning a query | SQLBits 2022 | 2022-03-08 |
Single T‑SQL query against Orders (100M) and OrderDetails (335M) returns 248 rows but starts as a hash join with a cluster scan, cold cache costing 5 million… | ||
| Dealing with Very Large Tables in SQL Server | SQLBits 2019 | 2019-02-27 |
Very large tables (10M–20B rows, multi‑TB) turn small mistakes into huge costs: an unindexed 20B‑row, 4.6TB table returns 3 rows with a 28‑minute, 72M… | ||
| When to stop tuning a query | SQLBits 2019 | 2019-02-27 |
A single T‑SQL query against two tables — 100 million rows in orders and 335 million rows in order_details — starts with a hash join, ~11s and 5 million… | ||
| nothing matches | ||