Andy Seaborne wrote:
What could be done is add better range index scans that started at a
particular value, and not look for "any" in that slot. However, the
biggest benefit is not hitting the NodeTable at all which is already
there.
Good.
So, if I have a TDB store full of events, we currently scan the entire
SPO index while we could scan just the fraction with values which satisfy
the FILTER expression.
More likely to look in POS, for fixed P, so it's a partial scan.
It'll look for [(P,0,0), (P+1,0,0)) fro P is the NodeId
I see, thanks.
If I have a large TDB store full of "events" this could still speed up
those queries, correct?
Yes, for a databse full such events. In the case you describe then it
might be beneficial to do
[(P,X1,0), (P,X2,0))
where X1 and X2 are the Nodeid encodings for the limits. It would need
a lot of data before that's going to be significant though - and also it
wil depend on whether it's better to do the rest of the BGP or the
constrained range scan.
Ack.
Another dirty workaround is adding more data to make the query more selective
(by YEAR, MONTH, DAY for example).
Paolo
I'll have a look (and come back with a description of how I understand
what could be done here).
Thanks,
Paolo
Andy
