Course contentsShow
← Databases & SQL
Lesson 577 of 1,9536. Query Performance and IndexingFree lesson

Large Object (LOB) Handling

Structure secondary storage for BLOBs to avoid inflating the main table b-tree size.

In this lesson, you will learn how to structure secondary storage for Large Objects (BLOBs) to prevent them from bloating your main table’s B-tree index and degrading query performance.

The Problem: B-Tree Bloat

When you store large files—like high-resolution images or long PDF documents—directly inside a table column, you run into a structural bottleneck. Database engines typically store row data in B-tree structures or pages. If a BLOB field is massive, a single row might span multiple pages, forcing the database to perform significant "page chasing" just to read basic metadata.

More importantly, because the B-tree tries to keep index entries compact, stuffing huge chunks of binary data into the primary storage pages forces the engine to push other rows out of the cache. This increases the total number of pages the database must scan, which destroys the efficiency of your SELECT queries.

The Solution: Externalizing Large Objects

To keep your performance predictable, treat the main table as a "directory" rather than a "warehouse." By offloading the BLOB data to a secondary storage structure—often called an OUT-OF-LINE store or a separate TOAST (The Oversized-Attribute Storage Technique) table—you keep your primary B-tree lean and mean.

In this design, the main table column simply stores a small pointer or reference (a few bytes) to the actual data located elsewhere.

-- Conceptual representation of an optimized schema
CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,
    username VARCHAR(50), -- Remains in the main B-tree
    profile_picture_ref UUID -- This points to a separate BLOB storage area
);

By separating the heavy binary payloads from the structured, frequently-queried metadata, you ensure that the database can perform full table scans or index lookups without dragging multi-megabyte objects through the memory buffers. This keeps your working set in the buffer pool small and maximizes your disk I/O throughput for the data that actually matters for your queries.

Key Takeaway: Never store heavy binary data in the main B-tree; move LOBs to secondary storage to keep index pages compact and ensure your hot data stays in the buffer pool.