I tried a vectorized PostgreSQL 19 on a laptop: 18 to 21% faster, and a 16,000-value ANY 948 times slower

This week two PostgreSQL stories came out that had nothing to do with each other. On Habr, in Russian, pg_vexec appeared: a vectorized executor for PostgreSQL 19 that comes in as an extension, without forking the engine, and that its author measured with ClickBench on a 16-core Ryzen. On Zenn, in Japanese, an engineer described how a query with 16,000 OR conditions loaded their database before it even ran: 56 seconds just to plan.

I wanted to see both on my own machine, and a modest one: a Lenovo IdeaPad with a 4-core i5-8250U and 12 GB of RAM. Putting them together turned up a third thing neither article mentions.

What pg_vexec is

PostgreSQL executes queries row by row: each plan node asks the one below for a row, processes it and hands it up. Analytical engines like DuckDB or ClickHouse work in batches: they take a thousand values of a column and apply the same operation to all of them at once, which is much kinder to the processor’s cache.

pg_vexec brings that idea to PostgreSQL 19 as a module loaded through shared_preload_libraries. It hooks into the planner and offers vectorized versions of scans, aggregations, joins and sorts that compete on cost with the regular ones. Whatever a vector kernel can’t compute falls back to PostgreSQL’s own evaluation, and vexec.mode decides: off is plain PostgreSQL, auto chooses by cost and force uses the vector version wherever it can.

How I set it up

The repository ships no images, so I built my own: PostgreSQL from the REL_19_STABLE branch (it reports itself as 19beta4), without assertions, and pg_vexec built with PGXS from its main branch. It compiled on the first try. For ClickBench I used the author’s own subset, every tenth row of the original file (9,999,750 rows, 6,866 MB per PostgreSQL), built with the author’s own script, and the settings ClickBench computes for this machine.

Two stumbles. The lenovo runs NixOS and had no Docker: I declared it in the system configuration before starting. And the first outside review of my numbers made me redo half the work: I had measured memory differently from the Japanese article, mixed times taken inside EXPLAIN ANALYZE with psql times, and always run the ClickBench modes in the same order on a laptop that heats up. All of that is fixed below.

ClickBench: it delivers

I ran the 43 queries in the three modes, two full passes in opposite orders, three tries per query with the system cache dropped before the first. The hot time is the best of the second and third tries, the way ClickBench computes it.

The author reported 19% on a 16-core Ryzen with 60 GB; on the laptop the gain lands between 18 and 21%. The biggest gains repeat in both passes and match the author’s: query 16 goes from 15.2 to 3.3 seconds, 29 gets 3.2 times faster and 15, 2.8. COUNT(DISTINCT) goes both ways: 10, 11 and 13 get slower in auto (0.60 to 0.64 times in the first pass, 0.52 to 0.55 in the second), 4 a little too, and 5 and 8 get faster; the author warns about the slow ones as well. force gives almost the same as auto. On the first tries of the first pass, right after the system cache is dropped, the three modes’ means land close (25.4 to 26.1 seconds).

What I cared about most was something else: that it wouldn’t change the answers. Every answer of both passes passes the author’s checker against DuckDB 1.5.5, with no errors. That checker is strict about order and ties, but for queries whose LIMIT cuts a run of tied rows it compares only the sort keys. Across the three modes, 32 of the 43 answers are byte-identical in the second pass (33 in the first); the rest are exactly the ones ClickBench leaves open: ties, a LIMIT without ORDER BY, and a sort on a column the query doesn’t return.

The huge OR, on five versions

The Japanese article uses an inventory table: 4 warehouses, 50,000 products and 4 receipt dates, 800,000 rows, with the primary key on the first three columns. The query asks for one day’s stock for a list of (warehouse, product) pairs, written as an OR of 16,000 conditions. I rebuilt it as is and ran it on PostgreSQL 15, 16, 17, 18 and 19.

Planning time grows with the square of the conditions on every version: 0.33 seconds for 1,000 pairs, 5.1 for 4,000, 21.6 for 8,000 and 90.5 for 16,000 on PostgreSQL 15; with 16,000 pairs, 16 takes 91.0, 17 takes 94.4, 18 takes 96.3 and 19, 87.6. Measured the way the article measured it, the process’s peak memory right after planning lands close: 22, 45 and 135 MiB against the 25, 48 and 140 MB it reports. No version changed that curve.

With 16,000 pairs the query didn’t even get to run in Docker: the parallel plan asks for a 73 to 82 MB shared memory segment and the container comes with 64 MB of /dev/shm by default. That’s a container trap, not a PostgreSQL one. With 1 GB, PostgreSQL 19 finishes it in 90.7 seconds, 87.3 of them planning.

The known way out is to rewrite the OR as an IN or an = ANY per warehouse: four conditions instead of 16,000. It plans in milliseconds and the whole query takes about 70 ms.

There’s another kind of OR that did change: the one that compares a single column with many values. PostgreSQL 18 started turning it into an ANY internally.

And a small regression along the way: the 16,000-value = ANY on that column takes 65 to 69 ms on PostgreSQL 15 to 17 and 225 ms on 18, which chooses to walk the primary key skipping its first column instead of a parallel sequential scan. PostgreSQL 19 is back to 71 ms.

Where they meet: the ANY that fools the vectorizer

With both set up, the obvious question was what pg_vexec does with the recommended rewrite. The answer surprised me. I measured it with two queries. The first asks for any product in a list of 16,000, in any warehouse, product_id = ANY (...), and returns 64,000 rows: in auto mode it goes from 73 ms to 69.3 seconds, 948 times slower. The second is the article’s, the (warehouse, product) pairs, with its two rewrites, IN and = ANY per warehouse, which return 16,000 rows: they go from about 70 ms to 16.9 and 16.8 seconds.

The plan explains half of it. With pg_vexec off, PostgreSQL looks the values up in the primary key with a bitmap scan, estimated at 15,913. In auto, pg_vexec prices its vector sequential scan at 14,588, cheaper than that plan and than the plain sequential scan (19,923), and takes it.

The code explains the other half. To estimate, pg_vexec takes the cost PostgreSQL computes for that = ANY, and with a constant array of 9 or more values PostgreSQL costs it the way it would run it: build a hash table once, at a cost per value, then charge a single lookup per row. pg_vexec, however, doesn’t hash when it runs: it compares the batch with each value of the array, one at a time, while any row is still undecided. A row that reaches that condition and matches no value goes through all 16,000 comparisons, and in the first query that’s two rows in three: the list holds 16,000 of the 50,000 products. The cost assumes one lookup per row and the execution, for those rows, does 16,000.

The funny part is that the first query written as an OR doesn’t fall for it: pg_vexec counts it as 16,001 steps, finds it expensive and keeps PostgreSQL’s index (189 ms against 185 with pg_vexec off). In other words, the rewrite that rescues the planner is the very one that fools the vectorizer’s estimator. And in force mode, with no choice, the OR goes to 31 seconds too.

What I cannot claim

It’s one machine, one subset and one setting per test. Two ClickBench passes aren’t enough for a confidence interval: the 18 to 21% range comes from those two. I didn’t record how many parallel workers actually launched in each query, only how many each mode planned (4 in all of them). The execution times I quote from EXPLAIN ANALYZE are instrumented; the comparisons that matter I repeated with psql’s own clock. And the reading of the code is mine: the report I prepared for the author presents it that way, with the lines cited.

My take

pg_vexec is serious work. It compiled without a fight, passed the ClickBench checker on every answer and repeated on a laptop the gain its author measured on a machine with four times the cores. That isn’t common in a project this new.

The problem I found is the mismatch between what it estimates and what it runs, and deciding when it’s worth it is the hardest part of an executor like this. The case doesn’t look exotic either: an application that turns a list of IDs into an = ANY with the values written into the query builds one of this shape. I didn’t test arrays passed as parameters or generic plans. The likely fix is to evaluate the ANY with a hash table, the way PostgreSQL does, or to charge it per element as long as it runs this way.

When I would use it and when not

• Yes, for analytical queries over large tables with aggregations, which is where ClickBench shows the gain, knowing it’s very new software on a PostgreSQL that is still in beta.
• Carefully, if your queries filter with = ANY or IN of hundreds or thousands of literal values: check the plan with EXPLAIN (VEXEC) and, if a Vec Seq Scan shows up where there used to be an index, leave that session at vexec.mode = off.
• For the huge OR, on any version: don’t build thousands of pairs with OR. Group them by the first column with IN or = ANY, and if you run PostgreSQL in Docker, raise /dev/shm above the default 64 MB.

Sources

• pg_vexec on GitHub, commit 634d868e85, and its design document with the author’s measurements (doc/vectorized-postgresql-extension.md). The 1,024-row batch is VEXEC_BATCH_ROWS; the ANY’s cost, plan/oracle.c together with the cost it takes from PostgreSQL (oracle.c and plan/cost.c), and its execution, expr/eval.c.
• The pg_vexec article on Habr (in Russian).
• The huge-OR article on Zenn (in Japanese).
• ClickBench, its PostgreSQL protocol and the hits dataset.
• The ANY in PostgreSQL 19: the hash table from 9 values and its cost.
• The PostgreSQL 18 release notes: the single-column OR turned into ANY and the scan that skips the index’s first column.
• PostgreSQL’s EXPLAIN documentation and log_planner_stats.
• The scripts, plans and raw data of every measurement.

Measured on 8 and 9 October 2026 on a Lenovo IdeaPad 81F4 (Intel Core i5-8250U, 4 cores and 8 threads, 12 GB of RAM) running NixOS 26.05 and Docker 29.8.1; PostgreSQL 19 from REL_19_STABLE at 2359968b449a (19beta4), pg_vexec 634d868e8549, PostgreSQL 15.19, 16.15, 17.11 and 18.6 from their official images, DuckDB 1.5.5.