On Postgres every write waits for the server's disk: a scan takes most of a second a feed #140
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found running the load tests on Postgres (#139) on 2026-10-05: the scratch daemon, in ipodderx_test on the databases project's server, read its first 1,500 feeds at 1.2 a second and had done 1,136 after ten minutes, where SQLite does them in 27s since #135.
Measured on that server: 200 single-row inserts, each its own commit, took 2,565ms, 12.8ms a commit waiting for the WAL to reach the disk (synchronous_commit=on); with synchronous_commit=off, 56ms; in one transaction, 67ms. A feed's entries and enclosures are written a row at a time, about 50 commits for a feed of 20 new items. Production runs on the same server with the same setting, so its scans pay this too, and so did every feed read whole after #130 forgot their ETags.
synchronous_commit=off for ipx's own sessions is #135's trade on Postgres: a crash of the Postgres server can lose the last commits, about the last 0.6s, and never corrupts anything; a crash of ipx loses nothing. Other databases on the server keep their setting.
Fixed in
8c4a5f3: ipx's Postgres sessions set synchronous_commit=off. The load harness's first scan of 1,500 feeds on Postgres went from over ten minutes (1.2 feeds a second) to 20s, and the Rust tests on Postgres from 7.1s to 3.3s. Deployed 2026-10-05 (0.10.1-dev); production's scans write the same way and get the same.