[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
> [Joe English]
> > What optimization strategies does the XQuery type system
> > enable? [...]
>
> The most important optimization in database languages is selection of
> indexes. By definition this needs to be done statically: if you have to
> look at the data in order to decide whether to use an index, the index
> serves no purpose.
>
> If the query is
>
> employee[salary > 100000]
>
> then to use an index on salary, at the very least you have to know that
> the index was built using the same assumptions about the ">" operator as
> the query is using. So some kind of static analysis is necessary.
IMO this is a design flaw. If XQuery didn't use overloaded
operators, static type analysis wouldn't be needed to optimize
this query.
(XPath has a similar problem: the evaluation strategy for
e.g. '/foo[$x]' is completely different depending on whether '$x'
evaluates to a number or to something else. One way to work around
this is to add static type-checking; another, better, way would be
to use a different surface syntax for context node position tests
than for predicates).
Static type analysis may be necessary in the presence of overloaded
operators, but I don't believe overloaded operators themselves are
a priori necessary. Perl for example uses '<' for numeric comparisons
and 'lt' for string comparisons.
> And
> some of the characteristics of the XPath 1.0 dynamic typing rules (which
> say, for example that "1.0" = "1" is false, but "1.0" <= "1" is true)
> become a major embarassment.
The Right Thing in my opinion is for type information to
be carried in the operators (a la Forth or Tcl), not in
values (dynamic typing) or in identifiers (static typing).
--Joe English
jenglish@flightlab.com
|
