Explain, Measured (PostgreSQL)

Four PostgreSQL arguments that came out even

Tue, 13 Oct 2026 00:00:00 GMT

Some advice gets repeated in code review because it sounds like it should matter. I picked four I have seen argued about and measured them. I expected at least two clear winners. I got three ties and one result that went the opposite way from the advice.

Setup

PostgreSQL 18.6, default settings. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. A 2,000,000-row table u with an id, an email, a status and a timestamp. Times are execution times from EXPLAIN (ANALYZE, TIMING OFF), warm cache, first run discarded, median of the rest.

IN, ANY or a VALUES join for 1,000 ids

	median	runs	buffers
`id IN (1999, 3998, ...)`	26 ms	15 to 54 ms	3,001
`id = ANY('{...}'::bigint[])`	19 ms	15 to 20 ms	3,001
`JOIN (VALUES ...) v(i) ON id = i`	20 ms	16 to 21 ms	3,001

All three read exactly the same pages. The medians differ, but one IN run took 54 ms and another 15 ms, so I would not read anything into the gap. Use whichever form your driver makes easy. ANY has one practical advantage when the array is passed as a single parameter: the statement text stays the same whatever the number of ids, which is kinder to prepared statements and to pg_stat_statements.

text, smallint or enum for a status column

Three values, two million rows, each stored three ways in its own one-column table.

	table	index
text	72.6 MB	13.9 MB
smallint	73.0 MB	13.9 MB
enum	72.7 MB	13.9 MB

Every row has a 24-byte header and is padded to 8 bytes, so a 2-byte smallint and a 7-byte 'active' end up the same size. The indexes are identical because B-tree deduplication stores each of the three values once with a list of row pointers. In a wider table the column order can change the padding, but the type of a short status column is not where the space goes. Choose it for what it lets you check.

Columns that are usually empty

One million rows with an id and ten more integer columns. In one table the ten columns are all NULL, in the other all filled.

	table	per row
ten NULL columns	44 MB	36 bytes
ten filled columns	77 MB	68 bytes

A NULL takes no space in the row. It costs one bit in the row's null bitmap. Optional columns that are mostly empty are close to free, which is worth knowing before splitting a table to save space.

count(DISTINCT) against GROUP BY

The advice I have seen most often: count(DISTINCT x) is slow, rewrite it as a count over a GROUP BY subquery. On two million unique emails:

	median
`count(DISTINCT email)`	1.95 s
`count(*) FROM (SELECT email FROM u GROUP BY email)`	3.12 s

The rewrite was slower. I am not claiming it always is. Which one wins depends on the plan the GROUP BY gets and on work_mem, and both change between versions and settings. That is the point: this is advice to check with EXPLAIN on your own data, not to apply.

What I did not test

IN lists with tens of thousands of values.
Status columns inside a wider row, where alignment can differ.
count(DISTINCT) with more work_mem, or on columns with few distinct values.
Other hardware. Compare the ratios, not the seconds.

Reproduce it

run2.py and results2.json. Sections 1, 9, 10 and 12 of the script.

What deleting rows does to a PostgreSQL table

Tue, 13 Oct 2026 00:00:00 GMT

A table that shrinks in rows does not shrink on disk. Everyone who has run PostgreSQL for a while knows this in general. I wanted the actual numbers, because "VACUUM reclaims space" means something narrower than it sounds.

Short answer: I deleted every second row of a 2,000,000-row table. The table was 137 MB before, 137 MB after the DELETE, 137 MB after VACUUM, and 68 MB after VACUUM FULL.

Setup

PostgreSQL 18.6, default settings, autovacuum on. 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. Sizes are pg_table_size. Times are wall clock for the statement, median of three runs, each on a freshly built table.

Deleting half the rows

step	table size
2M rows, after VACUUM ANALYZE	137 MB
after `DELETE FROM b1 WHERE id % 2 = 0`	137 MB
after `VACUUM b1`	137 MB
after `VACUUM FULL b1`	68 MB

The DELETE marks rows dead. VACUUM makes their space reusable, so the next million inserts will fill those gaps instead of growing the file. It does not hand the space back to the operating system, with one exception: empty pages at the very end of the file get cut off. I deleted every second row, so every page kept half its rows and nothing at the end was empty.

VACUUM FULL writes a new copy of the table and drops the old one. That is why it gets the space back, and also why it takes a lock that blocks reads and writes while it runs.

DELETE or TRUNCATE to empty a table

	time	WAL written
`DELETE FROM d1` (1M rows)	3.5 s	125 MB
`TRUNCATE d1`	0.05 s	44 kB

DELETE touches and logs every row. TRUNCATE gives the table a new, empty file. The difference grows with the table, and the WAL column matters if you have replicas or WAL archiving: 125 MB of WAL is 125 MB that has to travel.

TRUNCATE is not a drop-in replacement. It takes an ACCESS EXCLUSIVE lock, it does not fire ON DELETE triggers, and it refuses to run on a table that other tables reference with foreign keys unless you truncate those too or add CASCADE.

Updates and fillfactor

An update in PostgreSQL writes a new version of the row. If the new version fits on the same page and no indexed column changed, it can skip the indexes entirely. That is a HOT update.

I updated a non-indexed column on all 200,000 rows of a table, three times, once with the default fillfactor of 100 and once with 90, which leaves 10% of each page empty at load time.

	HOT updates	table after	index on `k` after
fillfactor 100	64 of 600,000	61 MB	10.4 MB
fillfactor 90	127,353 of 600,000	47 MB	9.0 MB

With full pages almost nothing could stay on its page. With 10% free, about a fifth of the updates did, and the table ended 24% smaller.

What surprised me

The HOT numbers were lower than I expected for fillfactor 90. Three full passes over every row use up the free space faster than a real workload that updates a few rows at a time, and autovacuum probably had no chance to clean up between passes. On a table where updates are spread out, the share of HOT updates should be higher. I did not measure that here.

What I did not test

Autovacuum doing its work between updates.
pg_repack or the new REPACK command in PostgreSQL 19 as alternatives to VACUUM FULL.
Tables with TOAST data, where some of the space lives in a separate table.
Other hardware. Compare the ratios, not the seconds.

Reproduce it

run2.py and results2.json. Sections 5, 6 and 11 of the script.

Five PostgreSQL queries that did more work than I asked for

Fri, 09 Oct 2026 00:00:00 GMT

Most slow queries I have looked at are not doing anything clever. They are doing extra work that nobody asked for, because one word in the SQL told PostgreSQL to.

I took five of those words and measured each one against the version without it, on the same table. The biggest gap was UNION: 13.6 seconds, against 0.68 seconds for UNION ALL on the same two halves of the table.

Setup

One table, u, with 2,000,000 rows: a bigint identity key, an email, a status, a timestamptz and an md5 note.

PostgreSQL 18.6, default settings (work_mem 4MB, shared_buffers 128MB, up to two parallel workers per query). Machine: 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM. Every time below is the execution time from EXPLAIN (ANALYZE, TIMING OFF), warm cache, first run thrown away, median of the rest.

Results

	without	with
UNION ALL / UNION	0.68 s	13.6 s	two halves that cannot overlap
CTE inlined / MATERIALIZED	0.24 ms	1,973 ms	filter on the primary key
TABLESAMPLE / ORDER BY random()	0.3 ms	1,313 ms	one random row
one column / SELECT *	32.8 ms	64.8 ms	about 100,000 rows by date range
expression index / no index	0.5 ms	623 ms	`WHERE lower(email) = ...`

UNION

I split the table at id = 1,000,000 and put the halves back together. With UNION ALL that is just reading the rows. With UNION, PostgreSQL has to make sure no email appears twice, so it deduplicates two million values before it can count them. It has no way to know the halves cannot overlap. I do, so I should have written ALL.

CTE with MATERIALIZED

WITH x AS (SELECT * FROM u) SELECT * FROM x WHERE id = 777777 took 0.24 ms. PostgreSQL 12 and later fold a CTE like this into the outer query, so the filter reaches the primary key index.

Add MATERIALIZED and it builds the whole CTE first, then filters it: 1,973 ms and every page of the table. The keyword is there for the cases where you want that fence. Here I did not.

One random row

ORDER BY random() LIMIT 1 reads all two million rows and sorts them by a random key to return one: 1,313 ms.

TABLESAMPLE SYSTEM (0.01) LIMIT 1 read one page and took 0.3 ms. It is not the same thing, though. SYSTEM picks whole pages, so rows that sit together come back together, and a sample this small can come back empty. For a quick look at some data it is fine. For anything that has to be fair, it is not.

SELECT *

About 100,000 rows by a created_at range, ordered by the same column, with an index on it. Asking for only created_at let PostgreSQL answer from the index alone: 279 buffers, 32.8 ms. SELECT * had to visit the table for every row: 1,718 buffers, 64.8 ms.

EXPLAIN ANALYZE does not send rows to the client, so none of this is network time. It is the table visits.

A function in WHERE

WHERE lower(email) = 'user1234567@example.com' with no matching index read the whole table in parallel: 623 ms. CREATE INDEX ON u (lower(email)) brought it to 0.5 ms and 4 buffers. An index on plain email would not have helped; the index has to be on the same expression the query uses. This one was 81 MB.

What surprised me

How small the fixes are. Four of the five are one keyword or one column list. The fifth is one index.

And how forgiving the slow versions look in development. On a table of a few thousand rows every one of these finishes in a few milliseconds, and the difference only appears when the table grows.

What I did not test

Larger work_mem. UNION would have deduplicated in memory with more of it, and the gap would be smaller.
Tables bigger than RAM. Everything here was in the OS cache.
Fair random sampling. TABLESAMPLE BERNOULLI samples rows rather than pages, which means reading every page; I did not time it.
Other hardware. Compare the ratios, not the seconds.

Reproduce it

The script and the raw numbers: run2.py, results2.json. The same script also measures the next two posts in this series.

UUIDs stored as text: what it costs in PostgreSQL 18

Tue, 06 Oct 2026 00:00:00 GMT

Last week I compared UUIDv4 and UUIDv7 as primary keys. There is a third case I left out: the key is a UUID, but the column is text. Some ORMs and JSON-first codebases end up there because a string is the easy path.

So I kept the same test and changed only the column type. 5 million rows, UUIDv7 and UUIDv4, each stored as uuid and as text. Short answer: the text index was 88% bigger, one level deeper, and every random lookup read one more page.

Setup

Same as last time. One table per run:

CREATE TABLE t (id <key> PRIMARY KEY, payload text NOT NULL);

The key was one of:

uuid DEFAULT uuidv7()
text DEFAULT uuidv7()::text
uuid DEFAULT gen_random_uuid()
text DEFAULT gen_random_uuid()::text

5,000,000 rows in 50 committed batches of 100,000, then VACUUM ANALYZE, a checkpoint, and two read queries. Three runs each on a fresh table, medians below. Machine: 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM, SSD. PostgreSQL 18.6 with OpenSSL (I checked this time), default settings, database collation C.

Results

	v7 uuid	v7 text	v4 uuid	v4 text
Insert 5M rows	26.6 s	32.5 s	46.7 s	79.3 s
WAL written	857 MB	1,104 MB	1,005 MB	1,545 MB
Table size	403 MB	482 MB	403 MB	482 MB
Primary key index	150 MB	282 MB	193 MB	364 MB
Index tree level	2	3	2	3
10,000 random lookups (buffers)	34,626	45,033	34,623	44,999

Buffers are shared hit plus read from the top plan node of EXPLAIN (ANALYZE, BUFFERS). Tree level is tree_level from pgstatindex.

Where the difference comes from

A uuid is 16 bytes. The same value as text is 36 characters plus a length byte: 37 bytes. Every index entry carries the key, so the text index holds more than twice the key data. It came out 88% bigger with v7 and 89% bigger with v4.

At 5 million rows, that was enough to add a level to the B-tree. The uuid index had a tree level of 2, the text index 3. A lookup walks from the root to a leaf, one page per level, so every lookup reads one more page. 10,000 lookups read about 10,400 more buffers, a little over one extra page each.

The table grew too, by 79 MB, because the heap stores the longer key as well.

What surprised me

Text made the bad choice worse, not just bigger. With v7 keys, text cost 6 seconds on insert. With v4 keys, it cost 33. My reading: random inserts into a bigger index split more pages and write more full-page images to WAL. The numbers point that way: 540 MB more WAL for v4, against 247 MB more for v7.

The cost I measured was size, not comparisons. I expected text comparisons to be the cost. Here the collation is C, which compares bytes, so comparisons are cheap. The cost I could measure was size: more pages, one more level.

What I did not test

Other collations. This database uses C. Most servers use something like en_US.UTF-8, where text comparison goes through the locale and costs more. I could not reproduce that faithfully on macOS, so the text numbers here are a best case.
Joins on text keys, and foreign keys referencing them. Every child table would carry the 37-byte value too.
Tables larger than RAM. The whole data set fit in the OS page cache.
The smaller sizes where both indexes have the same tree level. The extra page per lookup only appears once the text index is big enough to grow a level.
Other hardware. Compare the ratios, not the seconds.

If your keys are already text, changing the column to uuid is an ALTER TABLE ... TYPE uuid USING id::uuid, which rewrites the table and its indexes and takes a strong lock while it runs. I did not measure that here.

Reproduce it

The script and every raw number: run.py, results.json. It expects a PostgreSQL 18 server and the pgstattuple extension.

UUIDv4 or UUIDv7 for a primary key? 5 million rows on PostgreSQL 18

Tue, 29 Sep 2026 00:00:00 GMT

PostgreSQL 18 ships uuidv7() in core. No extension, no application code. So the old question comes back: if you want UUID keys, does the version matter?

I loaded 5 million rows three ways and measured. Short answer: UUIDv7 inserted in 27 seconds, UUIDv4 in 46. The v4 index came out 29% bigger. Random lookups by key cost the same.

Setup

One table per run:

CREATE TABLE t (id <key>, payload text NOT NULL);

The key was one of:

bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY
uuid DEFAULT gen_random_uuid() PRIMARY KEY (v4)
uuid DEFAULT uuidv7() PRIMARY KEY

Each run inserted 5,000,000 rows in 50 committed batches of 100,000. payload is an md5 string, 32 characters. After loading I ran VACUUM ANALYZE and a checkpoint, then two read queries. Every configuration ran three times on a fresh table. The numbers below are medians. The spread between runs was small, except insert time, which moved by up to 3 seconds.

Machine: a 2020 13-inch MacBook Pro, Intel i5-8257U, 8 GB RAM, internal SSD. PostgreSQL 18.6 built from source, default settings (shared_buffers 128 MB, max_wal_size 1 GB, full_page_writes on).

Results

	bigint	UUIDv7	UUIDv4
Insert 5M rows	23.2 s	27.0 s	46.3 s
WAL written	790 MB	857 MB	1,004 MB
Table size	365 MB	403 MB	403 MB
Primary key index	107 MB	150 MB	193 MB
Index leaf density	90%	90%	70%
10,000 random lookups (buffers)	34,228	34,650	34,632
Last 1,000 rows by key (buffers)	16	17	1,008

Buffers are shared hit plus read from the top plan node of EXPLAIN (ANALYZE, BUFFERS).

Where the difference comes from

A UUIDv7 starts with a millisecond timestamp, so each new key is larger than the last one. New index entries land on the rightmost leaf page, the same way a bigint sequence does. When that page fills, PostgreSQL starts a new one and leaves the old one full.

A UUIDv4 is random. Each insert lands somewhere in the middle of the index. Pages split, and after a split both halves are partly empty. That is the 70% leaf density, and it is most of why the v4 index is 43 MB bigger than the v7 one at the same row count.

The WAL number follows from the same thing. With random inserts, more distinct pages get touched between checkpoints, and the first change to each page after a checkpoint writes the whole 8 kB page to WAL. The v4 run wrote 147 MB more WAL than v7 for the same data.

What surprised me

My first run was wrong. I built PostgreSQL without --with-openssl. Without it, PostgreSQL falls back to a slower way of getting random bytes, and generating the UUIDs alone took 68 seconds for 5 million values. That made v4 and v7 look equally slow, and both looked five times slower than bigint. With OpenSSL, generation takes about 5 seconds for either version. Packaged builds (Homebrew, Debian, the Docker image) use OpenSSL, so the second set of numbers is the one that matches what you run. If you build your own, check.

Random lookups did not care. Fetching 10,000 random existing keys touched about 34,000 buffers for all three key types. Each lookup walks the index down to one leaf and then reads one heap page. The key's order does not change that walk much. I expected the bigger v4 index to cost more here, and at this size it didn't.

"Newest rows" is where v4 hurts. ORDER BY id DESC LIMIT 1000 read 17 buffers with v7 and 1,008 with v4. With v4 those are not the newest rows at all. They are 1,000 rows scattered across the table, one heap page each. If your application lists recent records, a v4 key needs a separate timestamp column and index to do it well. A v7 key already sorts by creation time.

What I did not test

Concurrent inserts from many sessions. This was one session.
Tables larger than RAM. The whole data set here fit in the OS page cache, so reads from "disk" were mostly memory. The gap on insert time may grow when the index no longer fits.
Updates, deletes, and foreign keys pointing at the key.
Replication. More WAL means more to ship, but I did not measure a replica.
Other hardware. The absolute seconds are laptop seconds. Compare the ratios, not the times.

One thing to know before switching: a UUIDv7 contains the time it was created. Anyone who can see the key can read that timestamp. If your keys are public and creation time is sensitive, that matters more than any number above.

Reproduce it

The script creates the tables, runs the inserts, and writes every raw number to results.json: run.py. It expects a PostgreSQL 18 server and the pgstattuple extension.