[query] Ensure optimal planning of unique-identity (and unique-value) attributes #144

New issue

Open

opened 2020-08-06 16:55:39 +00:00 by gburd · 0 comments

gburd commented

2020-08-06 16:55:39 +00:00

(Migrated from github.com)

Unique attributes, perhaps obviously, can produce no more than a single result each time they're evaluated, if their value place is bound.

As such, if the value place is bound — or we expect it to be, given hints from the input bindings — then we should consider handling that tuple first. If it yields no results, the query immediately short-circuits. If it yields a result, the rest of the query can proceed, probably with one less unbound place.

Note that we might need extra work to make sure that the vaet/avet index is used: #332.

Unique attributes, perhaps obviously, can produce no more than a single result each time they're evaluated, if their value place is bound. As such, if the value place _is_ bound — or we expect it to be, given hints from the input bindings — then we should consider handling that tuple first. If it yields no results, the query immediately short-circuits. If it yields a result, the rest of the query can proceed, probably with one less unbound place. Note that we might need extra work to make sure that the `vaet`/`avet` index is used: #332.