Hi!
Interesting ideas. I don't like the pragma idea that much because there is already sth. like that with xquery:eval. The thing I miss most is a function like xquery:eval that accepts a function as an argument but also takes a context and does that runtime optimization. Or a way to convert a function to string. Is there already sth. like this? I though it might be xquery:invoke but that seems to do sth. else.
Best regards
Omar
Am 18.09.2017 um 15:59 schrieb Christian Grün:
Hi Omar,
Our current XQuery optimizer opens the addressed database in order to find out if it has the required index structures, and if these are up-to-date. Moreover, the cheapest index lookup will be selected if there are several index candidates. For example, in the following query, it will be likely that the second predicate will be rewritten for index access:
db:open('persons')//person[country = 'Italy'][@id = 'id124']
If the addressed database is not statically known, these checks cannot be performed that easily. Further implications and in-depth information can be found in »Storing and Querying Large XML Instances« [1].
Here are two ideas how this could be tackled:
• We could add an XQuery pragma to enforce specific index rewritings. Examples:
for $n in 1 to 10 for $db in ('persons' || $n) for $person in db:open($db)//person where (# basex:index #) { $person/country = 'Italy' } where $person/@id = 'id124' return $person
(1 to 10) ! db:open('persons' || .)//person [(# basex:index #) { country = 'Italy' }] [@id = 'id124']
• We could create multiple query plans at compile time (with and without index, one rewriting for each index candidate) and choose the one that is expected to be the cheapest at evaluation time. This would definitely be the most flexible option (but the number of query plans increases exponentially if you have nested FLWOR expressions and queries with numerous predicates or where clauses).
Cheers, Christian