> 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.

I assume you are looking for something like the following query?

  xquery:eval-func(
    function($db, $name) { db:open($db)//person[name = $name] },
    [ 'persons', 'john' ]
  )

This sounds like an enticing idea. It is hard to realize, though, as
we would need to recompile code that has already been rewritten to an
internal representation that can be evaluated by our XQuery processor.

> Or a way to convert a function
> to  string.

Same here: It would require a lot of work to create a bug free XQuery
string representation of the internal code.




> 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's
>>    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
>>
>> [1] http://basex.org/about-us/publications/
>>
>

Reply via email to