Published
A hybrid Jev overlay sped up Postgres joins 12% on JOB, and made the planner slower
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%.
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.
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.
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.