On 14 Jul 2014, at 17:37, Bart Vandewoestyne <bart.vandewoest...@telenet.be> wrote:
> Our problem is the following: we observed that certain of our SPARQL
> queries have subqueries (that return IDs) that run rather slow (because
> of a slow bif:contains full-text-search). We therefore
> 'migrated'/'copied'/'flattened' some of our data to another
> technology/database/store that allows for faster textual search.
> Querying this database results in a list of IDs, and these IDs are then
> 'injected' in a SPARQL query (we simply create a SPARQL query string
> with all these IDs in the FILTER command).
>
> Apparently, we are limited to filtering 4094 IDs and I don't see a way
> to overcome this if the subquery returns more. Could there be a way to
> work-around this limitation at SPARQL level?
Couple of untested thoughts:
1. try to use several IN() filters by joining them using OR
FILTER(?id IN(1,2,3) or ?id IN(4,5,6))
2. use UNION to join result sets
{
… . FILTER(?id IN(1,2,3)
}
UNION
{
… . FILTER(?id IN(4,5,6)
}
3. insert IDs in separate named graph, use them for subquery and then clear the
graph
INSERT DATA {<id1> a <https://example.com/dummy> . <id2> a
<https://example.com/dummy> .} etc.
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
_______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
