We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Database Fundamentals
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Five lessons have printed EXPLAIN output and pointed at one word of it. The rest of the line is the planner showing its working, and it is where every plan decision comes from.

rows= is what the planner expected before executing anything. actual rows= is what the node really produced.
When those two differ by orders of magnitude, nothing below that line was chosen on good information. Adding an index to a plan picked from a wrong row count usually changes nothing.

Every plan here is a real plan from EXPLAIN with ANALYZE and BUFFERS, against a PostgreSQL the lab starts and tears down.

Sixty cities spread across twenty states, and every city is in exactly one state. Filtering on both is the same as filtering on the city alone.

The statistics PostgreSQL keeps are per column. There is nowhere in that structure to record that one column determines another.
Correlated columns are everywhere in real schemas, because real data is full of facts that determine other facts. Order date and shipped date, country and currency, product and category are all the same shape.