Bugs item #2898944, was opened at 2009-11-17 09:27 Message generated for change (Comment added) made by tsheyar 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: Closed >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: 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
