Very slow Fuseki FTS search queries for v4.21+

[jamiefeiss]

When performing search via the /search endpoint for SEARCH_METHOD=fts_fuseki, versions 4.21 and above produce significantly slower SPARQL queries. I believe the ordering of pattern matches in the underlying SPARQL query may be the culprit.

I've tested the underlying query from multiple versions, and propose to move the pattern match below the nested select block.

Average response times (SPARQL straight to Fuseki):

v4.20	v4.21+	Proposed Fix
~0.06s	~13.5s	~0.06s

CONSTRUCT {
    ?focus_node <https://prez.dev/type> <https://prez.dev/FocusNode> .
    ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?prof_1_node_1 .
    ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?prof_1_node_1 .
    ?hashID <https://prez.dev/searchResultWeight> ?weight .
    ?hashID <https://prez.dev/searchResultPredicate> ?pred .
    ?hashID <https://prez.dev/searchResultMatch> ?match .
    ?hashID <https://prez.dev/searchResultURI> ?focus_node .
    ?hashID <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://prez.dev/SearchResult>
}
WHERE {
    {
        SELECT DISTINCT ?focus_node ?pred ?match ?weight (URI(CONCAT ("urn:hash:", SHA256(CONCAT (STR(?focus_node), STR(?pred), STR(?match), STR(?weight))))) AS ?hashID)
        WHERE {
            ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?prof_1_node_1 . # introduced in v4.21
            ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?default_class_var . # introduced in v4.23.1, replaces above line
            {
                {
                    (?focus_node ?weight ?match ?g ?pred ) <http://jena.apache.org/text#query> (<http://www.w3.org/2000/01/rdf-schema#label> <http://www.w3.org/2004/02/skos/core#prefLabel> <http://www.w3.org/2004/02/skos/core#altLabel> <http://www.w3.org/2004/02/skos/core#hiddenLabel> <https://schema.org/name> <http://purl.org/dc/terms/title> "sea" ) .
                    FILTER (!ISBLANK(?focus_node))
                }
            }
        }
        ORDER BY DESC (?weight)
        LIMIT 11
        OFFSET 0
    }
    ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?prof_1_node_1 .
    ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?default_class_var . # proposed move here
}

[recalcitrantsupplant]

is it possible to load the data to graphdb and try the same? there were query patterns that would time out in graphdb but run instantly in fuseki and vice versa, unfortunately the query optimisers didn't handle this well.

Moving to outside the subselect would change the semantics; this is where the property expansion / profile triples go once the focus nodes are selected in the subselect. For rdf type specifically it probably doesn't matter, but it would be best to keep the pattern in the subselect if possible.

Does changing the order of the triple pattern matches within the subselect also give better performance? i.e.

        WHERE {
            {
                {
                    (?focus_node ?weight ?match ?g ?pred ) <http://jena.apache.org/text#query> (<http://www.w3.org/2000/01/rdf-schema#label> <http://www.w3.org/2004/02/skos/core#prefLabel> <http://www.w3.org/2004/02/skos/core#altLabel> <http://www.w3.org/2004/02/skos/core#hiddenLabel> <https://schema.org/name> <http://purl.org/dc/terms/title> "sea" ) .
                    FILTER (!ISBLANK(?focus_node))
                }
            }
            ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?prof_1_node_1 . # introduced in v4.21
            ?focus_node <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?default_class_var . # introduced in v4.23.1, replaces above line
        }

There is a place to reorder triple patterns in the code. I'd need to confirm if it does the above. We could drive it off of the search method config setting assuming this is a fuseki specific optimisation