Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/compiler/semantics normalize.brg, 1.11, 1.11.2.1
On 12/01/2006 02:28 AM, Peter Boncz wrote with possible deletions:
The Moerkotte Queries (e.g. /ufs/boncz/moer) seduced me into implementing the "syntactic variant" solution to the problem discussed by Jens in the wiki: [...] I do *not* propose to propagate this to the HEAD automatically. The decision whether this rewrite is worth the while I leave to the Munich folks. It is a thing that helps mps (a lot, in fact for programmers that use X[Z] XPath notation rather than xquery notation for $x in X where Z return $x)
Stefan's automatic propagation however already did exactly that...
(I just played around with both versions and it seems that the algebra is not slower with these modifications. In Guidos q11 the modified version is even 500 msec faster. My interpretation is that some more rewrites on the algebra side are needed to fill the gap :).)
Anyway, on our standard benchmarking machine db2 (non-optimized 64-bits 32-bits oids gcc compile) we now get the following score on the Moerkotte Queries:
MXQ.14 MXQ.12 saxon q0 0.67 1.71 1.5 q1 0.26 0.33 1.6 q2 0.68 1.23 60 q3 2.38 DNF 209 q4 1.83 2.02 61 q5 2.74 DNF 166 q6 4.82 DNF 130 q7 2312 DNF 211 q8 DNF DNF DNF q9 DNF DNF DNF q10 DNF DNF DNF q11 DNF DNF 151 q12 0.14 DNF ?
I tried to get the numbers out of the algebra branch as well. On my Laptop (1700MHz, 1024MB Ram) I got better numbers for the first two queries compiled with milprint_summer (I only tried these two).
The algebra version compiles for 7 of the 13 queries (3 fail due to non existent reverse sorting in the algebra and the 3 others fail as f n:number is not implemented yet). Queries q0, q1, q2, q4, q5, q11, and q12 compile and in q0, q1, q5, q11, and q12 all joins are recognized (at least as far as I could see). q2 and q4 still each contain an undetected join because we lack the detection of conjunctive joins (until now).
In the following the measurements of a single(!) run for each query:
guido q0: alg: Comp 613.000 msec Load 51.719 msec Query 224.477 msec Print 1.319 msec
mps: Trans 242.385 msec Shred 59.625 msec Query 385.546 msec Print 1.128 msec
guido q1: alg: Comp 79.000 msec Load 52.124 msec Query 120.840 msec Print 16.844 msec
mps: Trans 62.809 msec Shred 51.907 msec Query 155.992 msec Print 17.736 msec
guido q2 - alg: Comp 473.000 msec DNF (dependent join)
guido q4 - alg: Comp 522.000 msec DNF (dependent join)
guido q5 - alg: Comp 03s 255 msec Load 50.975 msec Query 1369.837 msec Print 158.239 msec
guido q11 - alg: Comp 02s 010 msec Load 50.960 msec Query 1130.238 msec Print 74.269 msec
guido q12 - alg: Comp 145.000 msec Load 52.192 msec Query 53.572 msec Print 1.980 msec
On Mon, Dec 04, 2006 at 04:49:27PM +0100, Jan Rittinger wrote:
On 12/01/2006 02:28 AM, Peter Boncz wrote with possible deletions:
The Moerkotte Queries (e.g. /ufs/boncz/moer) seduced me into implementing the "syntactic variant" solution to the problem discussed by Jens in the wiki: [...] I do *not* propose to propagate this to the HEAD automatically. The decision whether this rewrite is worth the while I leave to the Munich folks. It is a thing that helps mps (a lot, in fact for programmers that use X[Z] XPath notation rather than xquery notation for $x in X where Z return $x)
Stefan's automatic propagation however already did exactly that...
oops, sorry, my fault!
should I revert the changes on the development trunk, or shall we leave them in?
Stefan
(I just played around with both versions and it seems that the algebra is not slower with these modifications. In Guidos q11 the modified version is even 500 msec faster. My interpretation is that some more rewrites on the algebra side are needed to fill the gap :).)
Anyway, on our standard benchmarking machine db2 (non-optimized 64-bits 32-bits oids gcc compile) we now get the following score on the Moerkotte Queries:
MXQ.14 MXQ.12 saxon q0 0.67 1.71 1.5 q1 0.26 0.33 1.6 q2 0.68 1.23 60 q3 2.38 DNF 209 q4 1.83 2.02 61 q5 2.74 DNF 166 q6 4.82 DNF 130 q7 2312 DNF 211 q8 DNF DNF DNF q9 DNF DNF DNF q10 DNF DNF DNF q11 DNF DNF 151 q12 0.14 DNF ?
I tried to get the numbers out of the algebra branch as well. On my Laptop (1700MHz, 1024MB Ram) I got better numbers for the first two queries compiled with milprint_summer (I only tried these two).
The algebra version compiles for 7 of the 13 queries (3 fail due to non existent reverse sorting in the algebra and the 3 others fail as f n:number is not implemented yet). Queries q0, q1, q2, q4, q5, q11, and q12 compile and in q0, q1, q5, q11, and q12 all joins are recognized (at least as far as I could see). q2 and q4 still each contain an undetected join because we lack the detection of conjunctive joins (until now).
In the following the measurements of a single(!) run for each query:
guido q0: alg: Comp 613.000 msec Load 51.719 msec Query 224.477 msec Print 1.319 msec
mps: Trans 242.385 msec Shred 59.625 msec Query 385.546 msec Print 1.128 msec
guido q1: alg: Comp 79.000 msec Load 52.124 msec Query 120.840 msec Print 16.844 msec
mps: Trans 62.809 msec Shred 51.907 msec Query 155.992 msec Print 17.736 msec
guido q2 - alg: Comp 473.000 msec DNF (dependent join)
guido q4 - alg: Comp 522.000 msec DNF (dependent join)
guido q5 - alg: Comp 03s 255 msec Load 50.975 msec Query 1369.837 msec Print 158.239 msec
guido q11 - alg: Comp 02s 010 msec Load 50.960 msec Query 1130.238 msec Print 74.269 msec
guido q12 - alg: Comp 145.000 msec Load 52.192 msec Query 53.572 msec Print 1.980 msec
-- Jan Rittinger Database Systems Technische Universität München (Germany) http://www-db.in.tum.de/~rittinge/
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
On Wed, Dec 06, 2006 at 05:54:27PM +0100, Stefan Manegold wrote:
[...]
Stefan's automatic propagation however already did exactly that...
oops, sorry, my fault!
should I revert the changes on the development trunk, or shall we leave them in?
[...]
I did not deeply look into Peter's code, but it seems okay to me. (The pattern he uses to detect chances for rewriting is pretty restrictive, so the rewrites should be safe, I think.)
So, I'd say: just leave them in.
My 2¢
Jens
participants (3)
-
Jan Rittinger -
Jens Teubner -
Stefan Manegold