Assemble the first answer and take its price
O que você vai aprender
- assemble a finished desk answer out of the chapter’s techniques and take its cost in the same motion
- read someone else’s query from two numbers and tell whether it reads more than it needs to
- see the map of the course: eight chapters as eight layers of one answer
- know the honest frame of the course: what runs live here, what has been substituted, and what is missing altogether
The first answer on the panel
The end of the first shift. The supervisor comes for the answer to the top line of his sheet: which of the regular visitors most often sees the thing through — orders a material and gets it into his hands instead of abandoning it half-way.
For this question you do not need to go down to the raw events. The room already has a mart, dm_vydacha: one row per visit, gathering how many actions the person took, how many materials he touched, how many he ordered and how many he received.
This is your mart. The archivist on desk duty assembles it during his shift, and the visitors read it all day long, one question at a time.
Do not confuse it with the mart that the intake level’s belt fills at night. That one has a different writer, a different reader and a different key.
We will assemble the first answer out of this chapter’s techniques: with the condition inside, suffixes, and the extreme value. But the work does not end at a correct number. We take the cost of the answer straight away — by the rule QUERY laid down back in the first lesson.

How to read someone else’s answer
The answer is ready. What matters now is something else: which numbers show that a query is reading more than it needs.
For a first check, two numbers are enough: how many rows were read and how many marks were touched.
The row count shows how much of the table the engine had to read at all. The marks show how many stretches of the layout that read landed in.
If as many rows were read as the table holds altogether, then nothing could be discarded up front. The query went through the whole table — even if a single row is left in the answer.
Now let us see where the difference in cost between two similar questions comes from.
The room’s mart is laid out by visitor and time. So the question “what did this visitor do” lands on the layout: the engine can skip the rest before it reads anything.
The question “what happened on such-and-such a day” fits this mart worse. The date is not in the key, so the engine has to look through every part in turn.
In the next cell the two questions stand side by side. Look not at the size of the answer, but at the cost of the read.
Eight chapters — eight layers of one answer
The first cell of the panel is done, but the panel itself is built for eight. Every chapter after this one adds another layer to the same desk:
- What it is measured in — an answer that has a cost. This chapter.
- The accuracy of counting — a number with a note beside it saying how exact it is.
- Lists — an answer that would have called for a join in a row store.
- The visitor’s path — did he get there, in what order, did he come back.
- Time — a daily series with no gaps in it.
- Layout — the same answer for half the cost, and proved by a number.
- Joins — an answer with a lookup that fitted into memory.
- The desk handed over — all of it together, on two machines, and the exam.
Chapters do not start from a blank page. The techniques stack up, and the three-column log runs through the whole course: question, technique, cost.
QUERY: The first cell is filled. Notice this: asking about a visitor came cheap. Ask the same mart about a day — and the cost changes. Not today; just remember the difference.
The honest frame of the course
From here the chapters close one after another. So it is worth agreeing now on what in the sandbox is real, what has been replaced by a teaching model, and what is missing here altogether.
Runs live: everything you see in the cells. A real ClickHouse 24.10, a real analysis of the query, real plans and real error messages — word for word the ones you will meet at work.
The room’s data is loaded afresh before every execution. So you cannot spoil it, and your edits in a cell run immediately.
Substituted, and the lesson says so: a table definition is read through DESCRIBE rather than SHOW CREATE; the information about parts is taken from a housekeeping column rather than a housekeeping database; several machines are portrayed by two local tables.
That simplifies the environment, but it does not stand in for the mechanism you are studying.
Missing altogether: the network between machines and its cost, background merging under load, disks of different speeds, neighbours sharing the server.
In every one of those adds a cost of its own. But the basic rule of the course does not change because of it: the less you read, the cheaper you answered.
About the tasks below. This chapter’s gate stands on tasks that open only on ClickHouse. The is set by the task itself, and solving them on Postgres is physically impossible. That is deliberate: a course about ClickHouse has to close with ClickHouse.
Interview question
How this comes up in interviews
A common phrasing: “Here is a query — how would you tell whether it is optimal?” The answer “I would look at the execution time” is too weak: time depends on the load and the environment.
What they want is an order of checks: take the plan, compare the number of rows read against the size of the table, and see whether the filter columns match the way the table is laid out.
The next question usually sounds like this: “and what if the filter is on a column that is not in the key?”
Then nothing can be discarded up front, and the query reads the whole table. That shows up not in the size of the answer, but in the number of rows read in the plan.
You have already seen both cases on one and the same mart: 1024 rows against 5272.
- Views and purchases per productEASY
- Total revenue per userEASY
- Most expensive purchased product per userEASY
- Bounce rate per deviceEASY
- Bounced vs engaged sessions per deviceEASY
Principais pontos
| question | technique | cost |
|---|---|---|
| Which five visitors received the most materials, and what share of their orders did each complete? | over the room’s mart, one row per visit | 1 part / 5272 rows / 5 marks |
| How many materials did visitor 43 receive? | a filter on the first column of the mart’s key | 1024 rows / 1 mark |
| How many titles were handed out on March 5? | a filter on a column that is not in the key | 5272 rows / 5 marks |
The first cell of the panel is filled. It now holds not only an answer, but its cost as well. The next archivist on duty can repeat the check from those numbers without asking you what exactly went on inside the query.
This chapter has given you a basic set of techniques: the condition inside the aggregate, suffixes on top of any root, the extreme value without a window. But something else matters just as much — every one of those techniques can now be judged by the cost of the read.
From here the questions get more awkward. The first of them sounds simple: “how many distinct?” And it will turn out to have five different right answers.
QUERY: Shift accepted, archivist on duty. One cell out of eight. The mart answered expensively about a day, and not because it is a bad mart. Somebody just laid it out that way. Soon that somebody will be you.