From cbd262e5db2e185af63772b481485d1abebe96cf Mon Sep 17 00:00:00 2001 From: tiennm99 Date: Fri, 14 Aug 2026 16:58:54 +0700 Subject: [PATCH] docs: correct the sizes the 4 KiB rebuild produced The databases came out of the first 4 KiB build at 288.6 MB and 237.7 MB, against the 302 and 247 the registry carried. That figure is a build guard and is also shown to the user before the SQL tab opens, so both uses were wrong by the same 5%. The gzip variant the host builds for the HEAD request is now 64 MB, and the published size claims in the deployment and architecture notes follow the same rebuild. --- datasets.json | 4 ++-- docs/deployment-guide.md | 4 ++-- docs/system-architecture.md | 6 +++--- web/src/lib/db-probe.js | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/datasets.json b/datasets.json index 4543006..08d6751 100644 --- a/datasets.json +++ b/datasets.json @@ -20,12 +20,12 @@ { "id": "2016", "expectedRows": 877460, - "dbSizeMb": 302 + "dbSizeMb": 288 }, { "id": "2017", "expectedRows": 861068, - "dbSizeMb": 247 + "dbSizeMb": 237 } ] } diff --git a/docs/deployment-guide.md b/docs/deployment-guide.md index a880c87..2a2ce3d 100644 --- a/docs/deployment-guide.md +++ b/docs/deployment-guide.md @@ -83,8 +83,8 @@ artifact — one missing line away from publishing it. files committed to a repository; the databases are built in CI and uploaded as a Pages artifact, and the documented Pages limits are a 1 GB published site and 100 GB/month of bandwidth, with no per-file figure. The two - databases are 302 MB and 247 MB. -- **Total artifact is about 552 MB**, inside the 1 GB site limit but with less + databases are 288 MB and 238 MB. +- **Total artifact is about 526 MB**, inside the 1 GB site limit but with less headroom than before: a third dataset of this size would not fit. The fallback is `sql.js-httpvfs`'s chunked mode, which splits a database into parts. - **Pages does compress the databases, and that is survivable.** The extension diff --git a/docs/system-architecture.md b/docs/system-architecture.md index 7834311..69d2568 100644 --- a/docs/system-architecture.md +++ b/docs/system-architecture.md @@ -189,7 +189,7 @@ total descending. whole; GitHub Pages serves everything with `Cache-Control: max-age=600`, and every rebuild relays SQLite's pages so the file changes even when the data does not, so that caching is cancelled by the host. Worth revisiting behind a - CDN with long TTLs, and it is the fallback if a single 300 MB file ever + CDN with long TTLs, and it is the fallback if a single 288 MB file ever becomes a problem. - **`sqlite-wasm-http`.** Maintained, and built on the official SQLite WASM rather than a 2022 fork, which is the better long-term footing. It does not @@ -200,7 +200,7 @@ total descending. but it ships a fallback backend that does not — so isolation is not the blocker, the missing length option is. - **Substring name search.** `LIKE '%x%'` cannot use an index, so it read the - whole 127 MB table. `name_word` keeps search by any word of a name without + whole student table. `name_word` keeps search by any word of a name without it. ## Risks and limitations @@ -220,7 +220,7 @@ total descending. fails loudly instead of returning nonsense. - **`sql.js-httpvfs` is unmaintained** (0.8.12, September 2022) and ships its own SQLite WASM. `sqlite-wasm-http`, on the official build, is the fallback. -- **Hosted size.** 552 MB for both datasets against the 1 GB GitHub Pages +- **Hosted size.** 526 MB for both datasets against the 1 GB GitHub Pages limit; a third dataset of this size would not fit. - **Excel format drift.** A new source file with an unseen header layout needs a new branch in `parser/internal/ingest/detect2016.go` or a new config. diff --git a/web/src/lib/db-probe.js b/web/src/lib/db-probe.js index 2312c54..c707ddd 100644 --- a/web/src/lib/db-probe.js +++ b/web/src/lib/db-probe.js @@ -3,8 +3,8 @@ * * `sql.js-httpvfs` sizes a file with a HEAD request. That request carries no * Range header, so the browser advertises gzip, and GitHub Pages answers with - * `Content-Encoding: gzip` and the length of the *compressed* body — 66 MB for - * a 302 MB database. The library rightly refuses to believe it and gives up + * `Content-Encoding: gzip` and the length of the *compressed* body — 64 MB for + * a 288 MB database. The library rightly refuses to believe it and gives up * with "Length of the file not known. It must either be supplied in the config * or given by the HTTP server." *