# 1.4 The Table (The Relation)
While the **[[Chapter 1/1.3 - The Shipping Container (The Page)|Page]]** is the engine's physical I/O unit, the **Table** (or Relation) provides the logical organization and schema mapping. Think of the Table as the massive architectural structure where all our shipping containers are stacked and organized.
## The Logical Blueprint
A table is defined by its **Schema**. This is the rigid, architectural blueprint that specifies which types of data are permitted in each column. Every suitcase (Tuple) that enters the table must strictly adhere to this blueprint, or the engine will reject it at the gate.
This rigid structure is what allows Postgres to be "Lazy." Because the engine knows the exact size and type of every column, it can calculate physical offsets with mathematical precision, jumping directly to the data it needs without having to "read" every byte in between.
```sql
-- Defining the schema for the species table
CREATE TABLE species (
id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT UNIQUE NOT NULL,
diet_type diet_category NOT NULL
);
```
Once the schema is defined (executed), the engine allocates the initial data files required to persist incoming shipping containers onto the disk.
### Physical Segmentation (Segments)
A table is physically represented as a series of 8KB pages stored in a file. However, most modern filesystems get grumpy at extreme file sizes. To manage this, Postgres imposes a strict **1GB threshold** for any single physical file.
If a table grows beyond 1GB, the elephant essentially grabs a hacksaw and starts a new **Segment** file directly next door (e.g., `16385`, `16385.1`, `16385.2`). To the end-user, the table is a single logical entity; at the storage layer, it is a neatly organized campus of 1GB buildings.
You can inspect the literal file path of a relation on disk:
```sql
-- Where is the 'animals' building located on my disk?
SELECT pg_relation_filepath('animals');
-- Output: base/13593/16385
```
## Table Forks: The Side Rooms
A relation is not merely a single list of data pages. For performance and management, Postgres separates different functional requirements into distinct files called **Forks**, or specialized **Side Rooms** in the table structure.
The primary data is stored in the **Main Fork**. However, the engine maintains supplementary structures to optimize access:
- **Free Space Map (`_fsm`)**: A quick sketch showing which shipping containers have empty space, allowing the engine to quickly locate a target for new suitcases.
- **Visibility Map (`_vm`)**: A bitmask indicating which containers hold ONLY fully alive, completely visible suitcases. This is critical for **Index-Only Scans**; if the bouncer at the door knows the whole container is safe, he doesn't even have to walk into the table to check the suitcases!
> [!TIP]
> **Segments vs. Forks**: Segments are just more of the same hallway (more space), while Forks are the different rooms (different functions) in the same building.
### Access Patterns: The Sequential Scan
In the absence of an index, the engine must perform a **Sequential Scan** (Full Table Scan). It begins reading at the first page of the relation and proceeds linearly through every segment until the predicate is satisfied or the end of the file is reached.
For large relations, this results in significant I/O latency and CPU overhead as every page must be loaded into memory and processed.
## Storage Reclamation (The Autovacuum)
Because data is abandoned rather than erased, tables naturally accumulate "dead" tuples over time—a state known as **Bloat**.
To reclaim this space, the **Autovacuum** background process scans pages to identify dead tuples and mark their space as reusable in the **Free Space Map**. This prevents the physical file size from growing indefinitely.
In the next chapter, we will look at **Indexes**—the specialized data structures that allow the engine to bypass the sequential scan and access targeted tuples with minimal I/O.
---
| ← Previous | ↑ Table of Contents | Next → |
| :--- | :---: | ---: |
| [[Chapter 1/1.3 - The Shipping Container (The Page)\|1.3 The Shipping Container (The Page)]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 1/1.5 - The Sharpie Ledger (MVCC)\|1.5 The Sharpie Ledger (MVCC)]] |