SebastianGruza commented on PR #2994: URL: https://github.com/apache/hugegraph/pull/2994#issuecomment-5572441836
**Re-measurement on `fefe3ca`, 2026-09-07** — same method and cluster as my comment of 2026-09-06, plus 27 new shapes for today's findings of @bitflicker64 (`hasKey()` / `hasValue()` and connective string ids next to a negative label). Report and raw data: [tag `pr-2994-2026-09-07`](https://github.com/SebastianGruza/hugegraph-validation/blob/pr-2994-2026-09-07/reports/pr-2994/fefe3ca/README.md). **Finding 2 of 2026-09-06 is closed.** On 1 M vertices, `g.V().has('age',gte(60)).out().hasLabel(neq('person'))`: master 17 ms, `ac641c6` `Too many records`, `fefe3ca` **12 ms** with plan `HugeGraphStep(Vertex,[age.gte(60)]), HugeVertexStep(OUT,vertex), HasStep([~label.neq(person)])`; the `where(__.not(__.hasLabel(..)))` variant 17 ms. Point lookups 2 ms. The full scans for `has(indexed).limit().hasLabel(neq)` are unchanged, as the PR description states. **Backend axis**: suite 170 OK / 4 BOTH-ERR, 115/115 J8 shapes identical on hstore and rocksdb. **Version axis** (rocksdb): suite unchanged since 2026-09-06; the 18 `score` shapes stay fixed. Among them is the mixed-key `or()` with a child traversal that @imbajin asked about on 2026-09-01: `g.V().has('score',gte(40)).or(hasLabel(neq('person')), has('cnt',5))` with `score` indexed on `person` only returns 180 on master and 240 on this head, the 60 missing robots included, identically on both backends. **`hasKey` / `hasValue` next to a negative label** (rocksdb, master vs `fefe3ca`): | Query | master | fefe3ca | |---|---|---| | `g.V().hasKey('age').hasLabel(neq('person'))` | **0** | 300 | | `g.V().hasKey('score').hasLabel(neq('robot'))` | **0** | 3000 | | `g.V().hasKey('fname').hasLabel(neq('person'))` | **0** | 200 | | `g.V().hasValue(20).hasLabel(neq('person'))` | **0** | 5 | | `g.V().hasLabel('firm').out('deal').hasKey('type').hasLabel(neq('person'))` | **0** | 100 | | `g.V('a').outE().hasKey('amount').hasLabel(neq('flow'))` | **0** | 120 | | `g.E().hasKey('amt').hasLabel(neq('flow'))` | **0** | 100 | | `g.V().hasKey('age').limit(100000).hasLabel(neq('person'))` | `Not support query: … containsk` | 300 | | `g.V().hasId(within('p00010','r0001').and(neq('r0001'))).limit(10).hasLabel(neq('robot'))` | `Not supported querying by id and conditions` | 1 | A bare `g.V().hasKey('age')` throws on both versions and both backends (the backends do not run CONTAINS queries), but with a label predicate master answers with an empty set and no error. At `fefe3ca` every shape returns the complete set, identically on hstore. The one change of direction: `hasKey('nope')` is 0 on master and `Undefined property key` on the PR, which is the better answer. **Two observations on the new code, not blocking** since master throws in both cases: `g.V().hasId(within('big00000010','mark0').and(neq('mark0'))).limit(10).hasLabel(neq('mark'))` is a full scan at 1 M (`Too many records`, plan `HugeGraphStep(vertex,[]), HasStep([~id.and(within(..), neq(..))])`), while the same shape without `.and()` is a 39 ms point lookup; the `within` list is a complete candidate set, so it could reach `HugeGraphStep` with the `neq` leaf attached as well. `testLocalConnectiveStringIds` pins the result set; a plan assertion would pin this too. `hasKey()` with a label is also a full scan, but there is no index to push there, so that is a limitation to record rather than a fix to request. **In short**: from my side there is nothing left I would close before merging. At this head the label semantics are complete and identical on both backends, finding 2 is closed by measurement, and the PR fixes two classes of silently empty answers on master (`score` behind a barrier-like step, `hasKey`/`hasValue` next to a label). -- 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]
