User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like Gecko) Ubuntu/11.04 Chromium/17.0.963.79 Chrome/17.0.963.79 Safari/535.11 Steps to reproduce: After upgrading to 4.2.1 (from 3.0.11) an advanced search that was used on 3.0.11 and returned data in an acceptable amount of time now causes a query that in excess of 5 minutes will not return data. The following is the scenario in our organization. We have groups that in addition to tracking their development work in our Bugzilla instance, time is also tracked. Each group will have multiple developers assigned to it and on a regular basis (weekly / monthly) the team leader will do queries in Bugzilla reporting on what the members worked on and time entered on the bugs. Given some developers work across many different projects (Products), and bugs worked on could be in any status at the time of the query it does cause for a pretty open query. The 3.0.11 query (see attachment bug-3.0.11.sql for resulting query) would look like this in the Advanced Search: Hours worked change by Dev1 OR Hours worked change by Dev2 OR Hours worked change by Dev3 OR Hours worked change by Dev4 OR Hours worked change by Dev5 OR Hours worked change by Dev5 OR AND Hours Worked changed after DATE (where date is usually withing the last 6 weeks) The 4.2.1 query (see attachment bug-4.2.1.sql for resulting query) would look like this in the Custom Search) [Match ALL of the following] [Match ANY of the following] Hours worked change by Dev1 Hours worked change by Dev2 Hours worked change by Dev3 Hours worked change by Dev4 Hours worked change by Dev5 Hours worked change by Dev5 [Match ANY of the following] Hours Worked changed after DATE (where date is usually withing the last 6 weeks) Actual results: The resulting query from 4.2.1 seems to have many ties to the longdesc table that seems to make it inefficient. Our current database contains 56000 plus BUGS records and 466,000 plus LONGDESCS records. Performing the query for one developer results in a very speedy return of data. Query for two returns data in an acceptable amount of time. Anything over 3 developers results in a query that is longer than acceptable. Expected results: Given the query worked in 3.0.11 in an acceptable amount of time and not in 4.2.1 we would consider this a regression. I realize Bug 67757 exists but don't believe this is a duplicate as this is performance of the query and not about the dataset being requrned.

Same root cause as bug 785565. The problem is that the rewrite of Search.pm in 4.2 broke the way to link several criteria against comments together.