Bugs item #2898944, was opened at 2009-11-17 09:27 Message generated for change (Comment added) made by stmane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2898944&group_id=56967
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: PF/compiler Group: Pathfinder "candidate" Status: Open Resolution: Fixed Priority: 6 Private: No Submitted By: Axel Belinfante (axelbel) Assigned to: Jan Rittinger (tsheyar) Summary: pf takes 'forever' (> 1 hour) to compile particular query Initial Comment: I don't know whether the following really qualifies as bug, or just is a case of 'user error by giving stupid input. In any case, I would like to bring this to your attention. When I compile a query for attached module definition with pf (may or aug or pre-nov version), compilation takes 'forever'. When I replace the clause ecv:to-human($g0, $human_type) by simple $g0 and remove definitions of $human_type and to-human it compiles almost instantly. It is the huge difference in compilation time that surprises me. The query I compile is: import module namespace ecv = "http://www.cs.utwente.nl/~belinfan/ecv"; at "/tmp/long-compilation.xq"; ecv:view-from-save("eprints-export-conv-fmt.xml") where tmp/long-compilation.xq is the attached module. What the query attempts to do: obtain results from the database, order these on two criteria, and when listing the results, insert human-readable headers. The human-readable headers are obtained by the to-human mapping from field value (used as ordering criterium) to human-readable string. At some point I just used if-then-else-if-then-else etc. to do the mapping, but that seemed slower to compile than the approach I took here. Suggestions for rewriting the query to a fast-compiling one would be considered as a fix too, I guess. ---------------------------------------------------------------------- >Comment By: Stefan Manegold (stmane) Date: 2009-11-18 12:03 Message: Axel, what about your original long-compilation.xq? Does that now work fine for you (i.e., with Jan's fix)? ---------------------------------------------------------------------- Comment By: Axel Belinfante (axelbel) Date: 2009-11-18 11:30 Message: I don't want to spoil the fun, but after the fix pf still runs pretty long on the file I just attached (long-compilation2.xq) top gives me: PID USER NI VIRT RES SHR P S %CPU %MEM TIME COMMAND 26940 dbguest 0 7164m 3.7g 172 4 R 27 96.5 14:07 /local/dbguest/Install/MonetDB-XQuery_Nov2009/bin/pf -T /tmp/talt11 I tried to kill it with ^C, without too much success (and I already started to fear that the machine was hung up on it), until a little later I saw (I started it as: time /path/to/pf xqueryfile) Killed 828.295u 39.446s 16:38.94 86.8% 0+0k 0+0io 5pf+0w Segmentation fault ---------------------------------------------------------------------- Comment By: Stefan Manegold (stmane) Date: 2009-11-18 11:03 Message: I think, adding a test (also) for this one should be done; it should be not only possible, but also easy: the query that (used to) compile for for than one hour is given, just make a test that calls pf to compile the query, sending the output to, say, /dev/null/ . If that finishes without error and within the default 1 minute timeout (or less, if desired/required; add a TSTNME.timeout file with a <1 scale factor), the test succeeded and everything is fine; otherwise, the test fails ... ... just an idea to help assessing and monitoring this issue and hence the stability and usability of MonetDB as such ... ... does not apply to this bug report, only; see also my email of last weekend ... ... if there is no time right no to add the test, keep the bug report open to remind us ... ... in fact, I do exactly that ... ---------------------------------------------------------------------- Comment By: Jan Rittinger (tsheyar) Date: 2009-11-18 10:20 Message: The reason for the 'forever' compile time is that the physical plan space blows up in a heuristic that tries to find good plan orders. I now added a check that avoids generating to many plans. I checked in the fix in the Nov2009 stable branch. I'm however not sure whether it makes it into the release -- probably not. So please get it from either CVS or nightly-builds. ---------------------------------------------------------------------- Comment By: Axel Belinfante (axelbel) Date: 2009-11-17 09:32 Message: not sure about category or group - chose seemingly most appropriate. even though I did not change default priority , having some answer for this (whether fix in code, or guideline for fast compiling query) would be very helpful. In my application the pf compilation run is triggered from a web-gui - fast compilation is very important there, and predicatable compilation times maybe even more. (i.e. it would be nice when all compilations would take the same order of time). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2898944&group_id=56967 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Monetdb-bugs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
