Database Indexing hard
Index Condition Pushdown (ICP) improves performance by:
- A Pushing the entire index metadata to the client application to ensure that all initial search filtering is performed locally without a network hop.
- B Evaluating `WHERE` clauses using index data inside the storage engine itself *before* reading the full table row to reduce expensive heap fetches.
- C Automatically caching the most frequently used index pages in the processor's high-speed L3 cache to bypass the operating system's internal page limit.
- D Applying a specialized, hardware-accelerated compression routine to the index structure to minimize the disk I/O required for large range scans.
Answer: B. Evaluating `WHERE` clauses using index data inside the storage engine itself *before* reading the full table row to reduce expensive heap fetches.
Normally, an index scan finds matching rows based on the index key and then immediately fetches the full rows from the disk to check any other `WHERE` conditions. Index Condition Pushdown (ICP) allows the database to check *all* relevant conditions that can be resolved using the index columns BEFORE touching the main table. If a row fails a secondary condition, the database skips the expensive 'heap fetch' entirely, significantly reducing random disk I/O for queries with complex filters.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Z-Order Curves (Geohashing) map 2D data to 1D strings for indexing. What is their primary weakness?
- In-Memory databases (Hyper, HANA) often favor Adaptive Radix Trees (ART). Why?
- Log-Structured Merge (LSM) Trees (RocksDB, Cassandra) optimize for Write Throughput. How does their disk IO pattern differ from B-Trees?
- In LSM compaction strategies, 'Universal' (Tiered) compaction prioritizes what over 'Leveled' compaction?
- In LSM trees, what is 'Space Amplification'?
- Why is it generally ineffective to index a 'Low Cardinality' column like `Gender` ('Male'/'Female')?