Hash routing removes the usual reason a parallel aggregation disappoints, which is lock contention on one shared map [4]. It adds two costs it cannot remove: a hash computed per record on the routing path, and a handoff per record across a goroutine boundary. On a counting workload, those two costs are most of the per-record work.
The published run is where that shows. One worker moved 11.7MB per second and eight moved 10.1MB/s [15], a wall-clock gap of 1.02 seconds [13] and a speedup of 0.86x, roughly 11% of what eight workers would give if the stage scaled linearly [18]. Neither throughput figure is fast for grouped counting, which points at the stage in front of the shards: logq's decoder builds the full ordered record for every line, whatever fields the query names [9]. Sharding behind a serial bottleneck buys coordination and no throughput. That is an inference from the decoder's contract rather than a profile, because the post reports elapsed times without a core count, a query, or a run count [16].
For -j 8 to win on someone else's logs, the per-record work inside a shard has to be big enough to pay for the hash and the handoff. logq computes percentiles as well as counts [3], and a percentile over many groups does more per record than a counter increment does. Cardinality has to cooperate too, since a group is pinned to one shard by its hash [4]: a single dominant group means one busy goroutine and seven idle ones. The equality check also ran at 16 workers over 2,000 records while the timing ran at 8 workers over 76.3MB [5][1], so neither measurement covers the other's conditions.
The commit order tells you what this team tested first. The three-valued MISSING/null/false evaluator and its generated truth-table tests land 28 minutes into the build, before the JSON decoder and before the CLI existed [10]; the decoder that replaces gjson lands four minutes later [7]; the parallel flag arrives about 23 hours after that [17]. The replacement targets two stdlib defaults precisely: every JSON number decoded to float64, which loses precision past 2^53 and hands back a confidently printed wrong trace ID with no error, and Go's undefined map iteration order [8]. BENCHMARKS.md records the case where the swap loses, a query reading one field out of thirty [9], and the hashes are in the post because the project's own dependency ledger treats the git log as the evidence trail [12].
A commit hash lets a reader re-run the correctness claim. The speed claim is the one thing here that has to be re-measured on the reader's own file and cores, and until someone does that, 16% describes a 76.3MB file and the machine it ran on [1][2][14].
