> (in memory or TDB?) TDB1
> > - are there other ways to write this query to make it more performant? > Not in ARQ ubnelss there are less adm:logEntry triples. No > The access to data triples is (S,P,O) where any of S/P/O can be ANY. > So you have (ANY, adm:logDate, ANY) > > Ideally, that would be for TDB: > > (ANY, adm:logDate, ANY, start O at "2020-08-01T00:00:00"^^xsd:dateTime) > > or generally > > (ANY, adm:logDate, ANY, min O, max O) Yes exactly! That would be a very good solution for this use case > There are complications with illegal literals, mixed types, and encoding > restrictions etc. but in TDB2 "2020-08-01T00:00:00"^^xsd:dateTime is > stored inline in the ) slot as binary so the index is partially sorted > for valid data, > > There are precision limits in the encoding for XSD datatime: > Only to millesecond accuracy, timezones must be units of 15 min (which > true for all valid tz at the time of writing). > > Invalid terms are not recorded inline. They are recorded faithfully but > it means the abbreviated range isn't going to see them. Ok yes, I imagine there is a lot of edge cases indeed... but I'm happy even if only normal cases work > > - is it worth reporting this on the SPARQL 1.2 github repo? > > It is an implementation issue, not a language design issue. Ok yes. Thanks! -- Elie
