Re: The State of Native XML databases

[Michael Rys]

And depending on your storage and indexing infrastructure, a cast may or may not make it impossible for the optimizer to chose an index.

Best regards
Michael

-----Original Message-----
From: http://x-query.com/mailman/listinfo/talk [mailto:http://x-query.com/mailman/listinfo/talk] On Behalf Of Jeff Dexter
Sent: Tuesday, August 21, 2007 3:20 PM
To: 'John Snelson'
Cc: http://x-query.com/mailman/listinfo/talk; 'Andrew Welch'
Subject: RE:  Re: The State of Native XML databases

And in fairness, this would likely vary based indexing technology, where the
casts appear in the query... the list goes on but my money's on strong
typing. A benchmark on this sort of thing across the various implementations
would be interesting but I doubt anyone's touched on this particular area.

Jeff.

-----Original Message-----
From: John Snelson [mailto:http://x-query.com/mailman/listinfo/talk]
Sent: Tuesday, August 21, 2007 3:09 PM
To: Jeff Dexter
Cc: 'Andrew Welch'; http://x-query.com/mailman/listinfo/talk
Subject: Re:  Re: The State of Native XML databases

Neither of us can really argue authoritatively about this without hard
timings - but I want to point out that 10000 date strings probably have to
come from 10000 nodes, and my money is on getting the nodes being the
bottleneck.

Casts don't even make the radar on profiles of Berkeley DB XML, partly
because using the correct index avoids them, but also because parsing an
xs:date doesn't involve IO.

John

Jeff Dexter wrote:
> Parsing a date string, no, parsing 10,000 date strings, quite
> possibly. I would strongly suggest to query authors out there that if
> strong typing is available in the product they use that, for the sake
> of performance and to avoid runtime casting errors, they use it.
>
> That's not to say they have to, and in fact many use cases, such as
> querying streaming sources, are often forced to use weak typing, and
> it works quite well for those cases. Nonetheless the more up-front
> knowledge an engine has in regard to what it's querying and the types
> of the nodes involved the better it should perform, especially when
> using types like date, double, etc.
>
> Jeff.
>
> -----Original Message-----
> From: http://x-query.com/mailman/listinfo/talk [mailto:http://x-query.com/mailman/listinfo/talk] On
> Behalf Of John Snelson
> Sent: Tuesday, August 21, 2007 5:32 AM
> To: Andrew Welch
> Cc: http://x-query.com/mailman/listinfo/talk
> Subject: Re:  Re: The State of Native XML databases
>
> Andrew Welch wrote:
>> But it can only do any of those things if you tell it that the String
>> '2007-08-21' is a date, and not just a String?
>>
>> Giving <date>2007-08-21</date> to the database can't be enough...
>
> Sure, that's why XSLT and XQuery allow you to cast values - there are
> even special rules that automatically cast values from an untyped XML
> document which make life easier in that case.
>
>> The way I was reading this thread was that if the type information
>> was stored in the database, the cost of creating the xs:date would be
>> incurred once and not once per query that uses the value?
>
> That's possible, but not mandatory. Besides, parsing a date string is
> probably not going to be the bottleneck in a well designed XML database.
>
> John
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>
>
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk




_______________________________________________
http://x-query.com/mailman/listinfo/talk
http://x-query.com/mailman/listinfo/talk