staffCloud Postgres platformPro answerTested in a controlled lab, with the output captured

You've got a 50 TB table. Walk me through what ANALYZE actually does at that size, does it read every page?

The trap in this question is the word every. It invites a long answer about scan costs when the correct answer is one word followed by a mechanism. Interviewers use it because the sampling behaviour is documented, easy to check, and routinely guessed wrong by people who have only ever seen ANALYZE finish quickly on small tables. The second half of the question is quieter and harder: if the sample is a fixed number of rows, what actually gets more expensive at fifty terabytes, and what does not? Answering that honestly, rather than declaring the operation free, is the difference between a correct answer and a credible one. This page covers the ninety-second version and the follow-ups that usually arrive with it.

What the interviewer is scoring

They score whether 'it samples, it does not full-scan' is your first sentence, whether you can name the 300 × default_statistics_target rule, and whether you understand the row target is flat as the table grows.

In short: The interviewer is checking that you know ANALYZE reads a bounded sample of blocks, not the whole relation, and that the sample size is fixed by default_statistics_target, not by how big the table is.

ProFrom a real interview loop

The spoken answer, backed by captured output

The question, the intro, what the interviewer is scoring, the reasoning outline, what you would verify and the follow-up probes are all open above. Pro unlocks the spoken answer to “You've got a 50 TB table. Walk me through what ANALYZE actually does at that size, does it read every page?”, the reasoning behind it, and the verification that backs it.
  • The full 90-second answer, written first person, the way you would actually say it
  • How I reason through it: the mechanism, the decision points, and where the claim stops
  • Verification steps with output captured verbatim from a controlled PostgreSQL 18 lab run.
  • Worked responses to the 3 follow-up probes listed above, plus the traps that lose the point

Card required. Cancel before day 7 and you are not charged.

Compare plans

How to reason through it

  • Lead with the headline: ANALYZE reads a bounded sample of blocks, not the whole table.
  • Name the rule, the sample targets 300 × default_statistics_target rows (30,000 at the default of 100).
  • Explain the two stages: a random sample of blocks, then a reservoir sample of rows inside them.
  • State the consequence and its limit: the row target is flat as the table grows, but the I/O to reach scattered blocks is not.
  • Give the lever: raise STATISTICS on a skewed column for a bigger sample, at the cost of a slower analyze and a larger statistics catalog.

What I would verify

  • Read the VERBOSE output: it states how many pages were scanned, how many rows were sampled, and the resulting row estimate.
  • Compare the sampled row count against 300 x the effective target to confirm which target is in force.
  • Check for per-column statistics overrides before blaming cluster settings for a slow ANALYZE.
  • Treat the resulting row estimate as an estimate, and confirm it against an exact count only when the decision needs one.

Follow-ups they push on

  • So is ANALYZE on a 50 TB table cheap or not?
  • What if a column has heavy skew and estimates are still wrong?
  • Where does the sampled data actually land?

The probes are open. Pro carries the spoken answer, the reasoning behind it, and the verification steps, including a worked response to each of these.

Concepts tested

ANALYZE internalsBlock samplingdefault_statistics_targetPlanner statistics

Learn it, run it, then say it

Three steps, in order. Nothing here is a detour.

Questions that go with this one