Warm tip: This article is reproduced from serverfault.com, please click

XQuery/Xpath optimization: query different parts of the same document

发布于 2020-12-03 00:10:29

Let's say we have XML files with different parts: title, description, text, note.

<book>
    <title>Some title</title>
    <description>Some description</description>
    <text>Some texte</text>
    <note>Some note</note>
</book>

Let's say we want to be able to query in these different parts. This can be done by different approaches.

For exemple, we want to query only in title and note.

approach 1 (basic verbose version)

for $result in (
    collection("path_to_my_collection")//title[ft:query(., "'word_to_search'")]
    , 
    collection("path_to_my_collection")//note[ft:query(., "'word_to_search'")]
    ) 

approach 2 (take this one from here)

for $result in collection("path_to_my_collection")//(title | note)[ft:query(., "'word_to_search'")]

approach 3 (this one seems to be advised by the documentation )

let $docs_and_parts :=
    for $parts in (collection("path_to_my_collection")//title, collection("path_to_my_collection")//note) 
    return 
        $parts
        
for $result in $docs_and_parts[ft:query(., "'word_to_search'")]

After reading the XQuery optimization technic, I'm wondering which one of these approaches is more efficient/fast for execution in large collections with many (more than 100) files?

Questioner
ag_1812
Viewed
0
wp78de 2020-12-04 10:17:49

I think the article mentioned all relevant aspects to consider when writing expressions for eXists-db, e.g. avoid unnecessary nested filters, prefer XPath predicates over where expressions, use group by, construct the initial node set once and use it as input for the main expression when querying multiple collections..

It would seem the 3rd approach is advised since it follows the recommendation to construct the initial node set before querying it.

However, approach 2 seems to solve this by relying only on XPath; which could be even better.

In the end, it depends on your input data and the implementation details of the optimizer. Following the general recommendations and common sense (e.g.g avoid nested loops, etc) should help in most cases but running tests and find out what actually works best in a given scenario might be still required for critical cases.