Bugs item #2757110, was opened at 2009-04-13 02:04 Message generated for change (Comment added) made by stmane You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2757110&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 CVS Head Status: Open Resolution: None Priority: 3 Private: No Submitted By: Peter Boncz (boncz) Assigned to: Jan Rittinger (tsheyar) Summary: plan_subexpression slow Initial Comment: many MTest benchmarks/XBench queries, among which for instance benchmarks/XBench/DC/SD/q10.xq fail due to timeout. It appears many queries now take ages to compile, with the routine 'plan_subexpression' being called in a very deep stack. Is there a bug in the optimization algorithm, or has physical optimization by now become so ambitious we need a mechanism in the pf compiler to keep the search sapce under control (or stop searching after a time or effort limit). ---------------------------------------------------------------------- >Comment By: Stefan Manegold (stmane) Date: 2009-08-11 11:52 Message: According to our TestWeb, no timeouts occur with any of the pathfinder/benchmark/XBench tests (anymore): http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTests103/index.html http://monetdb.cwi.nl/testing/projects/monetdb/Stable/pathfinder/.mTestsg103/index.html ---------------------------------------------------------------------- Comment By: Martin Kersten (mlkersten) Date: 2009-08-06 16:36 Message: It seems this has to wait for future improved versions. ---------------------------------------------------------------------- Comment By: Jan Rittinger (tsheyar) Date: 2009-04-14 11:45 Message: The physical plan generator was never designed to be especially intelligent. It (stupidly) enumerates all possible plans. In the past I tried to add some short-cuts to avoid too bad compilation performance. With the recent optimization a lot of the ordering constraints, that forced the plan space to stay small, were moved out of the way. Furthermore the optimization option Y made the schemas of the operators much wider. Mainly the latter change causes routine better_or_equal() to run into serious performance problems as e.g., for query benchmarks/XBench/DC/SD/q10.xq two plans are compared with 2061256 and 1374170 different orderings!! I would guess that the problem becomes less dramatic again with the MonetDB specific optimizations in place that restrict the schema width (see also bug #2757104). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2757110&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
