Fix the slow bootstrapping with `groupUpdates`

Fixes #1

1 files changed, 3 insertions, 18 deletions

diff --git a/readme.md b/readme.md
index 31e0edf..b7b9c4e 100644
--- a/readme.md
+++ b/readme.md
@@ -2,22 +2,7 @@
 2. Optional: have [nix](https://nixos.org/nix/) installed. If you *don't* use nix, delete line 3 of `main.hs`.
 3. Run `./main.hs` and the server will startup
 
-To bootstrap the db, do `curl -XPOST "localhost:3000/bootstrap"`.
+To bootstrap the db, do `curl -XPOST "localhost:3000/bootstrap"`. This takes
+like 3 seconds or so.
 
-This takes a while; on my machine it averages 181 records per second. It's IO
-bound, and in an un-optimized program GHC on Linux uses a single, blocking IO
-manager thread (on Windows it's non-blocking, [apparently][1]). This can be
-improved with the [Control.Concurrent][1] module, it which case we could launch
-as many IO threads as we want, and do probably 10k records per second. There's
-definitely an optimal amount of threads here, we'd have to test to find that.
-
-*However*, you can watch it bootstrap. In a separate terminal, do `curl
-"localhost:3000/count"` to see it updating. New POSTs will also work and update
-the database, even while it is bootstrapping, which is kinda cool.
-
-Try this in bash:
-
-    while sleep 1; do curl -s "localhost:3000/count" | jq '.count'; done
-
-
-[1]: https://www.stackage.org/haddock/lts-10.3/base-4.10.1.0/Control-Concurrent.html#g:10
+See `test.http` for some other examples.