# Page Operations ![[assets/arch_page_container.png|256]] **Page Operations** act as the glue between the "Shortcut Layer" (Indices) and the "Physical Layer" (The Heap). They are designed to optimize the I/O pattern of high-volume data retrieval. ### The Architectural Role When an index matches thousands of rows, fetching each row one-by-one (Index Scan) would result in disastrous "thrashing" of the disk head. Page operations (specifically the Bitmap Heap Scan) solve this by: 1. **Bitmapping**: Consuming a list of TIDs from an index and marking which 8KB pages contain those TIDs. 2. **Sequentialization**: Sorting the list of pages by their physical location on disk. 3. **Bulk Ingestion**: Reading the pages in physical order, turning random I/O into a series of smaller sequential reads. ### In the Explain Plan These operations appear as a two-stage process: a `Bitmap Index Scan` (the producer) followed by a `Bitmap Heap Scan` (the consumer). ```text -> Bitmap Heap Scan on animals (cost=5.33..15.67 rows=42 width=18) Recheck Cond: (species_id = 5) -> Bitmap Index Scan on idx_animals_species (cost=1.00..5.32 rows=42 width=0) Index Cond: (species_id = 5) ``` --- ![[Operations/Page/BitmapHeapScan]]