Published
Updated
A hybrid Jev overlay sped up Postgres joins 12% on JOB, and made the planner slower
This topic was created 31 days ago, and the information it contains may have evolved or changed since then.
Michael Malis asked Jev to help plan Postgres joins on the join order benchmark. Letting it pick the join order made queries twice as slow. Estimating filters, then overriding Postgres only when Jev was confident, improved geometric-mean time by 12%. On September 30, 2026 this desk timed a 100,000-row table on Postgres 18.6. A Jev call of about 900 ms dominated queries that took 0.15 ms to 7.7 ms. The 12% figure was not rerun.
Michael Malis posted a six-part thread on September 18: he used Jev to help Postgres plan joins, and after some tuning he reported a 12% geometric-mean speedup on the join order benchmark.
The first attempt gave Jev the query and Postgres statistics and asked it to pick the join order. That was about twice as slow. He says Jev often lacked table context and defaulted to the smallest table first.
Next he asked Jev how many rows a filter would match, then let Postgres plan from those estimates. Queries improved most when outside knowledge said something the catalog did not. On IMDB data, Postgres estimated 1 in 100,000 movies are sequels; Jev estimated 1 in 100, which he calls much closer. The same habit hurt when the question was about the dump itself. Asked how many metadata fields were about release dates, Jev was unsure, and one query ran an order of magnitude slower.
The version he kept is a hybrid. Postgres plans first. If Jev is confident, it can override that plan. He reports a 12% geometric-mean improvement and no queries that got dramatically slower.
The cost is planning time. A Jev API call, he writes, takes hundreds of milliseconds, so the planner got slower even when the chosen plan was better. He says more work is needed before this is usable in practice. The thread does not link a repository.
On September 30, 2026 this desk timed its own table, not JOB. Postgres 18.6 on an Intel Core i3-12100, 128 MB shared_buffers, 4 MB work_mem, 4 GB effective_cache_size, 100,000 rows in jevdesk.titles. After one discarded warmup, three EXPLAIN ANALYZE runs, median execution time: an indexed sequel count was 0.153 ms (Index Only Scan), the same count as a sequential scan was 3.418 ms, a notes scan for “continues an earlier story” was 6.557 ms, and a notes scan for the word sequel was 7.679 ms. jev-1.13.0 was given a false catalog line saying 1 in 100,000 rows are sequels. The table’s rate is 1 in 100. It chose 1 in 100,000 at confidence 0.94, in 938 ms, $0.000020 at list price. The indexed count plus that call is 938 ms. A second question included the true note count in the prompt and came back 1 in 100. A third question, with no table behind it, asked about release-date fields and returned confidence 0.29. The 12% geometric mean, the twice-as-slow join order, and the query that got about 10 times slower are still only in the thread. This machine has no IMDB dump and no per-query plan from his run.
This site's reading
Editorial notes evaluating claims against primary sources, contextualizing findings alongside related implementations, and defining technical terms.
Verify
The six-post thread is the only source. Malis reports three setups on the join order benchmark: Jev choosing join order (about 2x slower); Jev estimating filter match rates for Postgres to consume (helpful on some IMDB queries, and one query about an order of magnitude slower when Jev was unsure); a hybrid where Postgres plans first and Jev overrides when confident (12% geometric-mean improvement, no queries dramatically slower).
He says a Jev API call takes hundreds of milliseconds, so the planner itself got slower even when the planned query got faster. We did not rerun JOB. There is no repository in the thread.
On September 30, 2026 this desk loaded a local table instead. Postgres 18.6 (Ubuntu 18.6-0ubuntu0.26.04.1) on an Intel Core i3-12100, MemTotal 15,631,040 kB. shared_buffers 128 MB, work_mem 4 MB, effective_cache_size 4 GB. Database jevdesk, table titles, 100,000 rows, index on kind, ANALYZE already run. One discarded warmup session, then three EXPLAIN (ANALYZE, BUFFERS) runs. The time below is the median execution time. No other workload was pinned to the machine.
Count of kind = sequel, Index Only Scan: 0.150, 0.153, 0.159 ms, median 0.153 ms. The same count with index and bitmap scans disabled, Seq Scan: 3.410, 3.418, 3.423 ms, median 3.418 ms. Notes containing "continues an earlier story", Seq Scan: median 6.557 ms (6.543, 6.557, 6.913). Notes containing the word sequel, Seq Scan: median 7.679 ms (7.562, 7.679, 7.913). Actual counts: 1,000 sequel rows, 1,000 notes that continue an earlier story, 2,000 notes that contain the word sequel, because the standalone notes also match that pattern.
Jev was jev-1.13.0, alias jev-latest. The first question repeated a false catalog line, the one Malis described: statistics shown to the model said 1 in 100,000 rows are sequels. The table's real rate is 1 in 100. Jev chose 1_in_100000 at probability 0.96 and confidence 0.94, in 938.0 ms, 477 input tokens, $0.000020 at list price. Adding that call to the indexed count makes 938.153 ms against 0.153 ms for the query alone. The forced sequential scan is still about 3 ms. On this table the API call is the planning cost, and it is larger than any execution difference we measured. A 12% execution win would not show up.
A second question told the model that about 1,000 of 100,000 notes say a film continues an earlier story, then asked for that fraction. Jev chose 1_in_100 at 0.96, confidence 0.94, in 880.9 ms. The count was in the prompt, so this is not an independent estimate. A third question asked what fraction of metadata fields are about release dates. No table was built for it. The prompt said the sample showed genre, cast, and runtime, and no release-date field. Jev chose 1_in_100000 at probability 0.44, with 1_in_100 at 0.26 and 1_in_1000 at 0.24, confidence 0.29, in 1,005.0 ms. Malis's query that ran about 10 times slower when Jev was unsure was not reproduced. There is no execution plan behind that third call.
The join order benchmark was not loaded. The thread has no repository, no query list, no hardware note, and no Postgres version. His 12% geometric mean, the twice-as-slow join-order attempt, and the query that got worse are still his report. This desk's regression is the call itself: every measured query was slower once the API time was added, and the false catalog line was repeated at high confidence.
Compare
Browser, Tetris, and JevPilot demos give Jev a list of legal actions and let it pick. Malis first tried that with join order and lost. The version that worked looks more like SREGym's jev_submit or LangChain's refusal gate: Postgres still produces a plan, and Jev may replace it when its estimate is confident.
Wrong world knowledge (how common sequels are, versus how a specific dump is labeled) is the failure mode he names.
Terms
- Join order benchmark
- JOB, a standard set of join-heavy queries over IMDB-style data, used here as the reported test. The thread does not list which query subset or Postgres version.
- Selectivity
- The fraction of rows a filter is expected to keep. Malis asked Jev for this number and let Postgres plan from it.
- Hybrid override
- Postgres plans first. If Jev's estimate is confident, that plan can be replaced. The thread reports this avoided the 10x regression from blind overrides.