# Inspect table counts and size estimates

Coordinator DB does not expose a `system.parts` relation or part-type inventory. Use public table metadata for object counts and available size estimates. This answers which tables exist without assuming another database's physical maintenance model.

```sql
SELECT database, table_name, total_rows, total_bytes
FROM system.tables
WHERE schema_name = 'main' AND table_type = 'BASE TABLE'
ORDER BY database, table_name
FORMAT csv;
```

## Interpret the values correctly

`total_rows` and `total_bytes` are available estimates and can be NULL. They are not a guarantee of an exact count. For a specific table where accuracy matters, run `SELECT count(*)` against that table. Do not sum estimates and present them as a precise billing or capacity figure.

Filter by database and namespace when names repeat. The observing connection's temporary objects can also appear in metadata and should not be confused with persistent application tables.

## Investigate a growth problem

Compare the table's schema, known import boundaries and actual row count before changing ingestion behavior. If duplicate loads caused growth, reconcile identifiers and completed batches. If a query is slow, inspect its plan and request metrics rather than looking for a nonexistent part counter.

See [system.tables](https://coordinatordb.com/docs/reference/system-tables/tables), [system.columns](https://coordinatordb.com/docs/reference/system-tables/columns) and [query history](https://coordinatordb.com/docs/reference/system-tables/query-log).