From 40e8f95d4ce1ecdd289a741bd590cab1953fe147 Mon Sep 17 00:00:00 2001 From: "Joshua D. Drake" Date: Tue, 4 Aug 2026 12:23:36 -0600 Subject: [PATCH] docs: q2 on TimescaleDB is 5 ms, not about 2 The paragraph explaining why the one-host queries are far apart said TimescaleDB answers q2 "in about 2 milliseconds". The serial table in the same file says 5, and the 442x figure quoted three paragraphs above is 2,211 / 5. There is no 2 ms cell in that row; the nearest is q1 at 4. A number in the prose that disagrees with the table it explains is the specific failure #381 was written to correct, so it should not survive in it. Co-Authored-By: Claude Opus 5 (1M context) --- docs/benchmarks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/benchmarks.md b/docs/benchmarks.md index c63d2f1..6b47eb1 100644 --- a/docs/benchmarks.md +++ b/docs/benchmarks.md @@ -489,7 +489,7 @@ Rows Removed by Filter: 99995680 It reads all 667 row groups and filters 99,995,680 rows to return 4,320. The zone maps cannot help, because neither key is sorted in the stored order. Every stripe holds all 4,000 hosts. The minimum and maximum `hostname` of each group therefore covers the whole set. -TimescaleDB answers the same query in about 2 milliseconds. It excludes all but one +TimescaleDB answers the same query in 5 milliseconds. It excludes all but one chunk on time, then reads one `hostname` segment through an index. **So this table measures pgColumnar in the layout that suits it least.** A user with