On Tue, Dec 7, 2021, 1:55 PM Matt Whitby <matt.whi...@gmail.com> wrote:
I dare say running an lcase against each field doesn't help matters, but with no other way of doing a case-insensitive search (well, Regex - but who likes Regex?) I'm not sure. On this point alone, if it does turn out that string processing is what is costing you time, you might adjust your data to include a convenience property with county, district, and parish in lowercase. Then you could do a more direct (and cheaper) match. That having been said, it seems unlikely to me that timed-out queries are due to something as cheap as lowercasing. Have you tried peeling off some of those OPTIONALs to see how much they cost? Adam On Tue, Dec 7, 2021, 1:55 PM Matt Whitby <matt.whi...@gmail.com> wrote: > I have a Sparql question if that's okay. > > There are only around 8m triples in our test data, so pretty small. > > The query takes a good couple of minutes to run (and sometimes just times > out). > > I dare say running an lcase against each field doesn't help matters, but > with no other way of doing a case-insensitive search (well, Regex - but who > likes Regex?) I'm not sure. > > Any obvious ways to make it less bad? > > PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> > select ?s ?name > where { > > ?s <http://www.historicengland.org.uk/data/schema/simplename/name> ?name . > > OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/county> > ?county}. > OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/district/> > ?district}. > OPTIONAL {?s <http://www.historicengland.org.uk/data/schema/parish> > ?parish}. > > FILTER (CONTAINS(lcase(?county),"lewes") || CONTAINS( > lcase(?district),"lewes") || CONTAINS( lcase(?parish),"lewes")) > > } > limit 10 >
