How a query runs
Medium+14 XPPress Run and follow one SELECT through the database: parse → plan the cheapest path → index-scan → filter+join → result.
No visualization loaded.
Watch
—
Press Run to begin.
When you send a database a query, it doesn't run your sentence literally — it turns it into a PLAN and walks the data through stages. Press Run and follow one SELECT down the pipe: the database reads it, decides the cheapest way to get the answer (use an index, don't scan everything), fetches the rows, combines the tables, and hands the result back.
▸What does the 'planner' actually do?
It looks at all the ways it COULD get your answer and guesses which is cheapest. Scan all million rows? Or use an index to jump straight to the five rows you want? It estimates each and picks the winner. That's the magic of declarative SQL: you say WHAT you want, the planner figures out HOW.
▸Why is 'use the index' usually the chosen path?
Because scanning a whole table means reading every row — slow on a big table. An index lets the database leap straight to the matching rows in a few steps (it's a B-tree, like the index lesson). Far less work, so the planner almost always prefers it when a useful index exists.
▸What's the 'join' step doing?
Your query asked for an order AND the buyer's name, which live in two different tables. The join matches each order to its user row by id and stitches them together, so each result row carries both. It's how the database combines tables on the fly.
▸Can I see the plan the database picked?
Yes — put the word EXPLAIN in front of your query and the database shows you its plan instead of running it: which index it'll use, whether it'll scan, the order it'll join. It's how you find out WHY a query is slow.