# innodb

Published articles for innodb.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Covering Indexes and Index-Only Scans in PostgreSQL

DevFeed: [Covering Indexes and Index-Only Scans in PostgreSQL](<https://devfeed.tech/articles/covering-indexes-the-cheap-10x-that-most-schemas-leave-on-the-table-39591.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/39-covering-indexes-index-only-scans/>)

Author: hello@ankit-rana.com

Published: 2026-08-18T00:00:00Z

Content type: tutorial

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Query (disambiguation)](<https://devfeed.tech/topics/query.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [b-tree](<https://devfeed.tech/tags/b-tree.md>), [cache](<https://devfeed.tech/tags/cache.md>), [covering](<https://devfeed.tech/tags/covering.md>), [covering-index](<https://devfeed.tech/tags/covering-index.md>), [database-performance](<https://devfeed.tech/tags/database-performance.md>), [explain](<https://devfeed.tech/tags/explain.md>), [heap](<https://devfeed.tech/tags/heap.md>), [indexes](<https://devfeed.tech/tags/indexes.md>), [indexing](<https://devfeed.tech/tags/indexing.md>), [innodb](<https://devfeed.tech/tags/innodb.md>), [pages](<https://devfeed.tech/tags/pages.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [query](<https://devfeed.tech/tags/query.md>), [storage](<https://devfeed.tech/tags/storage.md>), [vacuum](<https://devfeed.tech/tags/vacuum.md>)

### AI overview

This tutorial explains why a normal index scan may still be slow: after finding matching entries, the database follows a pointer into the table for each row. Covering indexes store the selected columns in the index and can avoid those heap reads. In PostgreSQL, index-only scans also depend on the visibility map marking pages all-visible, while SELECT * prevents the technique from being fully effective.

### Source excerpt

A normal index scan finds matching rows and then follows a pointer into the table for every one of them, which is a random read per row. A covering index stores the columns the query selects, so the engine answers entirely from the index and skips those reads. In PostgreSQL this only works when the visibility map marks the pages all-visible, so an unvacuumed table will report Heap Fetches in EXPLAIN and give back most of the gain. SELECT star defeats the technique completely.

## How UUIDv4 Primary Keys Affect Database Insert Performance

DevFeed: [How UUIDv4 Primary Keys Affect Database Insert Performance](<https://devfeed.tech/articles/why-uuid-primary-keys-quietly-destroy-database-performance-39564.md>)

Original publisher: [Read original article](<https://ankit-rana.com/logs/12-uuids-primary-keys-performance/>)

Author: hello@ankit-rana.com

Published: 2026-03-16T00:00:00Z

Content type: article

Language: en

Sources: [Ankit Rana | Mechanical Sympathy](<https://devfeed.tech/sources/ankit-rana-mechanical-sympathy.md>)

Topics: [Database](<https://devfeed.tech/topics/database.md>), [MySQL](<https://devfeed.tech/topics/mysql.md>), [ordering](<https://devfeed.tech/topics/ordering.md>)

Tags: [b-tree](<https://devfeed.tech/tags/b-tree.md>), [database](<https://devfeed.tech/tags/database.md>), [database-performance](<https://devfeed.tech/tags/database-performance.md>), [fragmentation](<https://devfeed.tech/tags/fragmentation.md>), [innodb](<https://devfeed.tech/tags/innodb.md>), [latency](<https://devfeed.tech/tags/latency.md>), [mysql](<https://devfeed.tech/tags/mysql.md>), [performance](<https://devfeed.tech/tags/performance.md>), [system-design](<https://devfeed.tech/tags/system-design.md>), [uuid](<https://devfeed.tech/tags/uuid.md>)

### AI overview

This article explains how random UUIDv4 primary keys can reduce insert performance in clustered indexes. Random inserts land in the middle of B+ tree pages, causing page splits, fragmentation, additional writes, and buffer-pool churn. It recommends UUIDv7 or ULID, or an auto-increment clustered key with UUIDs in a unique secondary index.

### Source excerpt

The problem with UUIDv4 primary keys is not uniqueness, it is that random keys fight the storage engine's physical layout. In a clustered index the primary key is the table, so random inserts land mid-page, trigger page splits, leave pages half-full, and can inflate a 50 GB dataset to roughly 100 GB while wasting buffer pool on empty space. Use UUIDv7 or ULID, or keep an auto-increment clustered key with the UUID in a unique secondary index.