Count All Employees — Reading EXPLAIN Output in SQL

The problem

Scenario: Helix Systems' data analyst ran EXPLAIN on a full employees read and saw the planner estimating 20 rows for the scan — a figure the analyst suspects is stale because the HR systems team loaded new employee records without running the maintenance step that refreshes table statistics.

Task: Write a query to return the actual count of employees recorded in the system.

Assumptions:

The employees table holds one row per employee on record.

Output:

One row, holding the employee count.
Columns in this order: employee_count.

Schema · hr 4 tables

departments

id integer

name text

location text

budget numeric

salaries

id integer

employee_id integer

amount numeric

effective_date date

end_date? date

employees

id integer

name text

email text

department_id integer

manager_id? integer

hire_date date

title text

is_active boolean

job_history

id integer

employee_id integer

title text

department_id integer

start_date date

end_date? date

Check answerShift Ctrl ↵

Run previews · Check grades

Write a query, then run it to see results here.

Worked solution Try it yourself first

Solution query

SELECT
  COUNT(*) AS employee_count
FROM
  employees

The shape

The planner reported 20 rows for the full employee scan; running an unfiltered COUNT(*) returns the truth. The actual table count is the baseline every other row estimate in the plan is implicitly scaled against, so getting it right is the first sanity check.

Clause by clause

SELECT COUNT(*) AS employee_count returns the total row count of the table, labeled so the answer reads as a domain quantity. COUNT(*) counts every row, regardless of any column being missing — which is what a "how big is this table" question wants.
FROM employees reads the employee records. There's no WHERE because the planner's 20-row estimate was for the full scan; the comparison number has to be the full row count as well.

Why this matters

The number on a sequential-scan node in EXPLAIN is supposed to be the table's row count. When it's off by an order of magnitude (the actual count here is 60, not 20), every downstream estimate built on top of it inherits the same scaling error. A join above this scan will multiply two wrong row counts together; an aggregate above it will allocate the wrong amount of memory. Refreshing statistics with ANALYZE employees fixes the input number, and most of the downstream estimates correct themselves once it does.

You practiced reading EXPLAIN's row estimate as a planner artifact — the actual count is what you compare it to, and a large gap is the diagnostic signal.

Return the actual count of `employees` recorded in the system

The shape

Clause by clause

Why this matters

Reading explains SQL. Writing it, over and over with instant feedback, is what makes you fluent.