SebastianGruza commented on PR #2994: URL: https://github.com/apache/hugegraph/pull/2994#issuecomment-5580979800
**`e32a75f` checked on the same lab**, report under [tag `pr-2994-2026-09-08`](https://github.com/SebastianGruza/hugegraph-validation/blob/pr-2994-2026-09-08/reports/pr-2994/e32a75f/README.md). No change in any result set against `fefe3ca` on either backend (suite 170 OK, 115/115 J8 shapes). On the contents of `docs/negative-label-queries.md`: on HStore (PD + 3 store nodes, 1 M vertices) every fallback shape, `count()` variants included, ends in `Too many records(must <= 800000)` after about 0.9 s exactly as on rocksdb, so the "where the execution path enforces them" caveat can be dropped for HStore. On the same graph, `g.V().has('age',gte(60)).out().hasLabel(neq('person')).count()` takes 2.5 s on master hstore and 49 ms on this head, because master pushes the label into `HugeVertexStep` and the store evaluates it per adjacency query. One thing to check on `LocalSearchHasContainer`: `g.V().has('fname',Text.contains('gold')).limit(100000).hasLabel(neq('person')).explain()` prints ` HasStep([fname.TEXT_CONTAINS(gold)])` on hstore but `HasStep(lambda)` on rocksdb with the same build; the result sets are identical, so it may just be `toString()` after the matcher was built, but I would rather report it than guess. -- 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]
