Reading performance & plans
Concept  ·  SQL & Querying

A full scan where pruning was expected, and the wrong join strategy (broadcast vs shuffle/hash), are the two big plan smells.

A plan is the engine confessing its strategy. Smell one: SEQ_SCAN (full scan) feeding a predicate that keeps almost nothing — a missing index/partition or a predicate written unsargably (a function wrapped around the column). Smell two: estimated rows vs actual diverging by orders of magnitude — stale statistics or a correlated predicate, and every join strategy downstream inherits the bad estimate. Read before rewriting.

See it break
plays
machinescore
a10
b999
c20
d5
e30
The trap
SELECT
  machine
FROM
  plays
WHERE
  score + 0 > 900
ORDER BY
  machine;
The fix
SELECT
  machine
FROM
  plays
WHERE
  score > 900
ORDER BY
  machine;
The trap
b
The fix
b

Both queries return the same machine, but wrapping the column in score + 0 hides it from any prune — the plan shows a SEQ_SCAN reading all five rows to keep one, smell one of a slow query.

The rule

EXPLAIN (ANALYZE where available) read bottom-up; smell → cause → then the rewrite.

Shows up elsewhere
SargabilitySELECT * cost on columnar
Try one →Prove it in practice →