Re: About Saxon XQuery Processor
Arkadiusz Binder <[email protected]> Tue, 19 May 2015 10:20:38 +0200
| Newsgroups | gmane.comp.web.query-languages |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail-1B895464-C3EC-4CF4-8302-B1A9B4E715A6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We are doing similar subject. Is there a technology of using Saxon on server side with optimized querying b= ig xml files or xml collections in folders, where the data could be cached a= nd reindexed incrementally (based on updated files).=20 If I have many different queries with using big (above 1Giga) xml - then I c= ould move to native xml files only if the second query to such xml will not l= oad it again to memory. We are also doing some progress of transforming Xsd schema to remap objects t= o 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(schem= a, prefix:element, xpath) gives XML; write(schema,XML) writes . Now we are d= oing this interactive JavaScript form which will honor Xsd choices, referenc= es and occurs. We couldn't find any solutions with remapping Xsd to flat database tables.=20= Can I find somebody near this subject?=20 -- Arkadiusz Binder Stowarzyszenie Rozw=C3=B3j i Praworz=C4=85dno=C5=9B=C4=87=20 > On 18 maj 2015, at 22:08, Michael Kay <[email protected]> wrote: >=20 > You may be using the open-source Saxon-HE implementation, which does not h= ave a join optimizer; joins are a great deal faster in the commercial Saxon-= EE implementation. >=20 > 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 wo= uld expect them to perform equally well. In this respect Saxon is different b= ecause it works on ad-hoc XML data files, with no opportunity to build index= es manually in advance. Although Saxon-EE uses indexes to optimize joins, it= has to make the indexing decisions itself based on the actual query. >=20 > 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). Mo= st 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 r= elationships between primary keys and foreign keys. The focus in an optimize= r is always on optimizing the constructs that are most used. >=20 > Michael Kay > Saxonica >=20 >=20 >> On 18 May 2015, at 18:48, Yoonmoe Lay <[email protected]> wrote: >>=20 >> Dear everyone, >>=20 >> 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. >>=20 >> Best Regards, >> Ms. Lwin Moe Aung >=20 >=20 --Apple-Mail-1B895464-C3EC-4CF4-8302-B1A9B4E715A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div><br>We are doing similar subject.</div= ><div>Is there a technology of using Saxon on server side with optimized que= rying big xml files or xml collections in folders, where the data could be c= ached and reindexed incrementally (based on updated files). </div><div>= If I have many different queries with using big (above 1Giga) xml - then I c= ould move to native xml files only if the second query to such xml will not l= oad it again to memory.</div><div><br></div><div>We are also doing some prog= ress of transforming Xsd schema to remap objects to small xml files or api c= alls. We found about 12 conditions of transforming XSD ( e.g. where to insta= nce many derivations) - at the moment : read(schema, prefix:element, xpath) g= ives XML; write(schema,XML) writes . Now we are doing this interactive JavaS= cript form which will honor Xsd choices, references and occurs.</div><div><b= r></div><div>We couldn't find any solutions with remapping Xsd to flat datab= ase tables. </div><div>Can I find somebody near this subject? </di= v><div><br></div><div><br><div style=3D"font-family: UICTFontTextStyleBody; -= webkit-text-size-adjust: auto;">--</div><div style=3D"-webkit-text-size-adju= st: auto;"><font face=3D"Gill Sans" size=3D"1"><i>Arkadiusz Binder</i></font= ></div><div><div style=3D"font-family: 'Gill Sans'; -webkit-text-size-adjust= : auto; margin: 0px;"><span style=3D"letter-spacing: 0px;"><i><font size=3D"= 1">Stowarzyszenie Rozw=C3=B3j i Praworz=C4=85dno=C5=9B=C4=87 </font></i= ></span></div><div style=3D"font-family: 'Gill Sans'; -webkit-text-size-adju= st: auto; margin: 0px;"><br></div></div></div><div>On 18 maj 2015, at 22:08,= Michael Kay <<a href=3D"mailto:[email protected]">[email protected]</a>> wrot= e:<br><br></div><blockquote type=3D"cite"><div><span>You may be using the op= en-source Saxon-HE implementation, which does not have a join optimizer; joi= ns are a great deal faster in the commercial Saxon-EE implementation.</span>= <br><span></span><br><span>However, all SQL implementations that I know of r= un 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 i= mplementations designed to run on a database environment with a similar appr= oach to indexing, and I would expect them to perform equally well. In this r= espect 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 in= dexes to optimize joins, it has to make the indexing decisions itself based o= n the actual query.</span><br><span></span><br><span>Also, I think the equi-= join operation is a lot less important when dealing with hierarchic data (XM= L) than when dealing with relational data (SQL). Most of the time with XQuer= y, the relationships you need to use in a query are the hierarchic relations= hips implicit in the XML, rather than value-based relationships between prim= ary keys and foreign keys. The focus in an optimizer is always on optimizing= the constructs that are most used.</span><br><span></span><br><span>Michael= Kay</span><br><span>Saxonica</span><br><span></span><br><span></span><br><b= lockquote type=3D"cite"><span>On 18 May 2015, at 18:48, Yoonmoe Lay <<a h= ref=3D"mailto:[email protected]">[email protected]</a>> wrote:</spa= n><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><= blockquote type=3D"cite"><span>Dear everyone,</span><br></blockquote><blockq= uote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><= span> I am= a computer science master student from</span><br></blockquote><blockquote t= ype=3D"cite"><span>Myanmar. Now, I am doing analysis of querying system for S= QL and</span><br></blockquote><blockquote type=3D"cite"><span>XQuery. May I k= now why XQuery ( that used Saxon) is slower than SQL in</span><br></blockquo= te><blockquote type=3D"cite"><span>Join queries? I want also to know why XQu= ery is faster than SQL expect</span><br></blockquote><blockquote type=3D"cit= e"><span>Join queries. Please answer my questions as soon as possible. Thank= a</span><br></blockquote><blockquote type=3D"cite"><span>lot.</span><br></b= lockquote><blockquote type=3D"cite"><span></span><br></blockquote><blockquot= e type=3D"cite"><span>Best Regards,</span><br></blockquote><blockquote type=3D= "cite"><span>Ms. Lwin Moe Aung</span><br></blockquote><blockquote type=3D"ci= te"><span></span><br></blockquote><blockquote type=3D"cite"><span></span><br= ></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><block= quote type=3D"cite"><span></span><br></blockquote><span></span><br><span></s= pan><br></div></blockquote></body></html>= --Apple-Mail-1B895464-C3EC-4CF4-8302-B1A9B4E715A6--