serhiy-bzhezytskyy opened a new pull request, #18:
URL: https://github.com/apache/solr-orbit-workloads/pull/18
### What this changes
One character in `nyc_taxis/operations/default.json`, and the `README.md`
row that describes it:
```diff
- "query": "total_amount:[5 TO 15]"
+ "query": "total_amount:[5 TO 15}"
```
Upstream's `range` operation is:
```json
{ "range": { "total_amount": { "gte": 5, "lt": 15 } } }
```
`lt` is exclusive. Solr spells an exclusive bound with a curly bracket, so
`[5 TO 15]` widens the
query by everything that equals exactly 15.
### Why it is worth one character
For a benchmark, three documents out of a thousand cost nothing measurable —
I checked, and the
latency difference is inside the noise (12 runs, 0–4 ms either way, no
ordering). So this PR is not
really about the query. It is about the question *"how would anyone know?"*,
which for a ported
workload has to be answerable without a reviewer reading two DSLs side by
side and trusting the
reading.
The way I try to answer it is to run the two engines against the same
documents and compare counts.
Neither `[5 TO 15]` nor `lt: 15` is self-evidently right or wrong when read;
they only disagree when
something is sitting exactly on the boundary.
**On the corpus this workload ships with** (`documents-1k.json`, 1,000
documents, Solr 10.0.0 —
`solr:latest`, `solr-impl 10.0.0 6c6c48a6f78`, Lucene 10.3.2):
| query | hits |
|---|---:|
| `total_amount:[5 TO 15]` — what `main` ships | 576 |
| `total_amount:[5 TO 15}` — this PR | **573** |
| `total_amount:15` | 3 |
**On a 300,649-document sample** of the same 2015 green-taxi data: 191,735
vs **191,441**, a
difference of 294.
**And on OpenSearch, against its own body**, on the same 1,000 documents:
`lte: 15` returns 576 and
`lt: 15` returns 573. ⇒ The upstream engine draws the boundary where this PR
draws it, so the port
was the side that moved.
The three boundary documents, so the claim is checkable rather than just
counted — each has
`total_amount` exactly 15, is returned by `main`'s query, and is not
returned by upstream's:
| `trip_distance` | `fare_amount` | `tip_amount` | `total_amount` |
|---:|---:|---:|---:|
| 0.13 | 14.0 | 0.0 | 15.0 |
| 19.79 | 14.5 | 0.0 | 15.0 |
| 3.63 | 13.5 | 1.0 | 15.0 |
### The same defect one level up
The port did not invent this: `solr-orbit`'s converter produces the
inclusive form for *any* `gt`/`lt`
it is given, because it reads only the bound values and never the operator.
So a hand fix here would
be undone the next time anyone regenerates the workload. Both halves are
open:
* `apache/solr-orbit#68` — the bug, with the same measurement
* `apache/solr-orbit#69` — the fix, with tests that are red without it
This PR is the shipped-workload half. They are independent — either can land
first — but the
converter one is the one that stops it recurring.
### Verification
`--test-mode` run of the whole workload against Solr 10.0.0, with solr-orbit
at plain `origin/main`
(`2.1.0-45-g81bbcab5`, none of my local changes) so the numbers are what a
reviewer would get:
```
✅ SUCCESS
15 of 15 tasks at 0% error rate
documents in nyc_taxis after indexing: 1000
```
I check the document count explicitly because a run can report `SUCCESS`
while a task fails 100% of
its requests — every search afterwards then succeeds at 0% error against an
empty collection, which
is how I lost a day earlier in this port. The count is the part that cannot
be satisfied by an empty
index.
`range` is a Solr-syntax query string, so the direction is the one that
matters: the changed query
was executed against Solr, not only parsed.
### What I am *not* claiming
* No performance claim. The two forms are indistinguishable in latency at
this scale.
* No claim that the other nyc_taxis operations are correct. I have
differences recorded for
`distance_amount_facet` (a filter dropped in translation) and
`date_histogram_fixed_interval`
(`+30DAY` for a `60d` interval, and the histogram not anchored to the
epoch the way OpenSearch
anchors it). Those are larger and want their own PRs with their own
measurements; I would rather
establish the method on a one-character change first.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
