v2.3.4

API responses are compressed on the wire

• Every response now goes out gzip/br/deflate-encoded for clients that ask for it. The periodic /stats chart and scoreboard pulls are JSON that compresses roughly five to ten times, and uncompressed they arrived as an egress burst large enough to bufferbloat a 100 Mbit uplink and delay the stratum notify queued behind it.
• A no-op for clients that send no Accept-Encoding, so nothing about the response bodies themselves changed.

Chart ranges: a 14-day preset

• ?range=14d joins 1d, 3d, 7d and 1m at the same native 10-minute resolution — 2016 points where a 30-day request returns 4320.
• It exists because the /stats page never reads further back than 14 days and had to ask for the 30-day payload to get there, so roughly half of every response was transferred, parsed and discarded.
• Additive: 1m is unchanged, and every endpoint that already took range accepts the new preset. /api/info/chart/mode/:mode keeps its own narrower set of 1d, 3d and 7d.

Database: page headroom so the busiest statistics table can update in place

• Of client_statistics_entity's 106.7 M updates only 16.7 % reused their page; the rest wrote a new entry into all five of its indexes, which is how 274 MB of table accumulated 794 MB of index. The four sibling tables measure 78-99 % and are deliberately left alone.
• No indexed column changes on the upsert path, so the cause is page space: a row about twenty counter columns wide, updated roughly ten times per 10-minute slot, at fillfactor 100. Migration 0015 sets fillfactor 80 on that one table.
• find_client_statistics and find_client_difficulty_statistics had no caller and are gone. They were the only readers of id on those two tables, whose primary-key indexes are otherwise maintained on every insert for nothing.

Upgrade notes

• Migration 0015 runs at boot. It does not rewrite the table and takes no exclusive lock. Only newly written pages carry the reserve, so the effect arrives gradually as the 14-day retention turns the table over.
• It does not reclaim the existing index bloat. That needs a REINDEX CONCURRENTLY, which cannot run inside a migration's transaction and stays a separate operator step.
• The cost is table size, about 20 % more for the same rows. Reversible with ALTER TABLE client_statistics_entity RESET (fillfactor); — neither direction touches data.
• If 2.3.3 was never deployed, its upgrade notes still apply on top of these. Migrations 0013 and 0014 then run at the same boot, and 0013 is not backward-compatible with an older core image.