About Saxon XQuery Processor

Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

About Saxon XQuery Processor

Yoonmoe Lay
Dear everyone,

             I am a computer science master student from
Myanmar. Now, I am doing analysis of querying system for SQL and
XQuery. May I know why XQuery ( that used Saxon) is slower than SQL in
Join queries? I want also to know why XQuery is faster than SQL expect
Join queries. Please answer my questions as soon as possible. Thank a
lot.

Best Regards,
Ms. Lwin Moe Aung




Reply | Threaded
Open this post in threaded view
|

Re: About Saxon XQuery Processor

Michael Kay-3
You may be using the open-source Saxon-HE implementation, which does not have a join optimizer; joins are a great deal faster in the commercial Saxon-EE implementation.

However, all SQL implementations that I know of run on persistent data in a database, and joins usually perform best when you have pre-built indexes on the relevant data fields. There are many XQuery implementations designed to run on a database environment with a similar approach to indexing, and I would expect them to perform equally well. In this respect Saxon is different because it works on ad-hoc XML data files, with no opportunity to build indexes manually in advance. Although Saxon-EE uses indexes to optimize joins, it has to make the indexing decisions itself based on the actual query.

Also, I think the equi-join operation is a lot less important when dealing with hierarchic data (XML) than when dealing with relational data (SQL). Most of the time with XQuery, the relationships you need to use in a query are the hierarchic relationships implicit in the XML, rather than value-based relationships between primary keys and foreign keys. The focus in an optimizer is always on optimizing the constructs that are most used.

Michael Kay
Saxonica


> On 18 May 2015, at 18:48, Yoonmoe Lay <[hidden email]> wrote:
>
> Dear everyone,
>
>             I am a computer science master student from
> Myanmar. Now, I am doing analysis of querying system for SQL and
> XQuery. May I know why XQuery ( that used Saxon) is slower than SQL in
> Join queries? I want also to know why XQuery is faster than SQL expect
> Join queries. Please answer my questions as soon as possible. Thank a
> lot.
>
> Best Regards,
> Ms. Lwin Moe Aung
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About Saxon XQuery Processor

Arkadiusz Binder

We are doing similar subject.
Is there a technology of using Saxon on server side with optimized querying big xml files or xml collections in folders, where the data could be cached and reindexed incrementally (based on updated files). 
If I have many different queries with using big (above 1Giga) xml - then I could move to native xml files only if the second query to such xml will not load it again to memory.

We are also doing some progress of transforming Xsd schema to remap objects to small xml files or api calls. We found about 12 conditions of transforming XSD ( e.g. where to instance many derivations) - at the moment : read(schema, prefix:element, xpath) gives XML; write(schema,XML) writes . Now we are doing this interactive JavaScript form which will honor Xsd choices, references and occurs.

We couldn't find any solutions with remapping Xsd to flat database tables. 
Can I find somebody near this subject? 


--
Arkadiusz Binder
Stowarzyszenie Rozwój i Praworządność 

On 18 maj 2015, at 22:08, Michael Kay <[hidden email]> wrote:

You may be using the open-source Saxon-HE implementation, which does not have a join optimizer; joins are a great deal faster in the commercial Saxon-EE implementation.

However, all SQL implementations that I know of run on persistent data in a database, and joins usually perform best when you have pre-built indexes on the relevant data fields. There are many XQuery implementations designed to run on a database environment with a similar approach to indexing, and I would expect them to perform equally well. In this respect Saxon is different because it works on ad-hoc XML data files, with no opportunity to build indexes manually in advance. Although Saxon-EE uses indexes to optimize joins, it has to make the indexing decisions itself based on the actual query.

Also, I think the equi-join operation is a lot less important when dealing with hierarchic data (XML) than when dealing with relational data (SQL). Most of the time with XQuery, the relationships you need to use in a query are the hierarchic relationships implicit in the XML, rather than value-based relationships between primary keys and foreign keys. The focus in an optimizer is always on optimizing the constructs that are most used.

Michael Kay
Saxonica


On 18 May 2015, at 18:48, Yoonmoe Lay <[hidden email]> wrote:

Dear everyone,

           I am a computer science master student from
Myanmar. Now, I am doing analysis of querying system for SQL and
XQuery. May I know why XQuery ( that used Saxon) is slower than SQL in
Join queries? I want also to know why XQuery is faster than SQL expect
Join queries. Please answer my questions as soon as possible. Thank a
lot.

Best Regards,
Ms. Lwin Moe Aung






Reply | Threaded
Open this post in threaded view
|

Re: About Saxon XQuery Processor

Liam R. E. Quin
On Tue, 2015-05-19 at 10:20 +0200, Arkadiusz Binder wrote:
> We are doing similar subject.
> Is there a technology of using Saxon on server side with optimized
> querying big xml files or xml collections in folders, where the data
> could be cached and reindexed incrementally (based on updated files).

You are wanting an XML-native database, I think; there are several of
these, both open source and commercial. Some relational databases also
include XQuery support.

> If I have many different queries with using big (above 1Giga) xml -
> then I could move to native xml files only if the second query to
> such xml will not load it again to memory.
>
> We are also doing some progress of transforming Xsd schema to remap
> objects to small xml files or api calls. We found about 12
> conditions of transforming XSD ( e.g. where to instance many
> derivations) - at the moment : read(schema, prefix:element, xpath)
> gives XML; write(schema,XML) writes . Now we are doing this
> interactive JavaScript form which will honor Xsd choices, references
> and occurs.
>
> We couldn't find any solutions with remapping Xsd to flat database
> tables.

XML documents have hierarchy and sequence as native properties.
Relational database tables have neither of these. As a consequence,
relational databases tend not to be a good fit for modeling XML.

In specific cases, though, you could design an XML Schema Document to
be easily represented in a relational form, or you could design an XML
Schema Document so that XML instance documents that conformed to such a
schema could themselves be stored in a relational database. Without
knowing what you mean in more detail it's difficult to answer your
questions.

Liam

--
Liam Quin, W3C XML Query Working Group team contact.


> Can I find somebody near this subject?
>
>
> --
> Arkadiusz Binder
> Stowarzyszenie Rozwój i Praworządność
>
> > On 18 maj 2015, at 22:08, Michael Kay <[hidden email]> wrote:
> >
> > You may be using the open-source Saxon-HE implementation, which
> > does not have a join optimizer; joins are a great deal faster in
> > the commercial Saxon-EE implementation.
> >
> > However, all SQL implementations that I know of run on persistent
> > data in a database, and joins usually perform best when you have
> > pre-built indexes on the relevant data fields. There are many
> > XQuery implementations designed to run on a database environment
> > with a similar approach to indexing, and I would expect them to
> > perform equally well. In this respect Saxon is different because
> > it works on ad-hoc XML data files, with no opportunity to build
> > indexes manually in advance. Although Saxon-EE uses indexes to
> > optimize joins, it has to make the indexing decisions itself based
> > on the actual query.
> >
> > Also, I think the equi-join operation is a lot less important when
> > dealing with hierarchic data (XML) than when dealing with
> > relational data (SQL). Most of the time with XQuery, the
> > relationships you need to use in a query are the hierarchic
> > relationships implicit in the XML, rather than value-based
> > relationships between primary keys and foreign keys. The focus in
> > an optimizer is always on optimizing the constructs that are most
> > used.
> >
> > Michael Kay
> > Saxonica
> >
> >
> > > On 18 May 2015, at 18:48, Yoonmoe Lay <[hidden email]>
> > > wrote:
> > >
> > > Dear everyone,
> > >
> > >            I am a computer science master student from
> > > Myanmar. Now, I am doing analysis of querying system for SQL and
> > > XQuery. May I know why XQuery ( that used Saxon) is slower than
> > > SQL in Join queries? I want also to know why XQuery is faster
> > > than SQL expect Join queries. Please answer my questions as soon
> > > as possible. Thank a lot.
> > >
> > > Best Regards,
> > > Ms. Lwin Moe Aung
> >
> >