Bug 1266261 - Slow bug searching when searching on short_desc
Summary: Slow bug searching when searching on short_desc
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Bugzilla
Classification: Community
Component: Query/Bug List
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: 5.0-RH10
Assignee: Jeff Fearn 🐞
QA Contact: tools-bugs
URL:
Whiteboard:
: 1264851 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-24 22:27 UTC by Matt Tyson 🤬
Modified: 2025-10-16 23:42 UTC (History)
2 users (show)

Fixed In Version: 5.0.4-RH40
Clone Of:
Environment:
Last Closed: 2020-04-01 12:20:16 UTC
Embargoed:


Attachments (Terms of Use)

Description Matt Tyson 🤬 2015-09-24 22:27:08 UTC
Bugzilla seems to generate a search that is incredibly slow on postgresql.

It seems to happen when a search is done involving the bug summary (short_desc)

An advanced search like this:

f1 => OP
j1 => OR
f2 => keywords
o2 => casesubstring
v2 => foo
f3 => short_desc
o3 => substring
v3 => bar
f4 => bug_group
o4 => equals
v4 => groupname
f5 => CP

In plain english,  
IF keywords contains the substring 'foo' 
OR summary contains the substring 'bar' 
OR the bug is in the 'groupname' group

This causes bugzilla to emit a query like so

WHERE bugs.bug_id IN (1,2,3,4 .. 20000)
OR bugs.short_desc ILIKE '%bar%'
OR bugs.bug_id IN ( another bug_id list here)

Postgres seems to really struggle with the bugs.short_desc ILIKE '%bar%' clause.
The query can take up to 5 minutes to complete.  If it is removed then the query will finish in a matter of seconds.

A possible way to optimize this is to perform the short_desc search in a separate query and return the list of bug_ids, as the other two search terms do.

Comment 1 Matt Tyson 🤬 2015-09-24 23:08:51 UTC
> Postgres seems to really struggle with the bugs.short_desc ILIKE '%bar%'
> clause.
> The query can take up to 5 minutes to complete.  If it is removed then the
> query will finish in a matter of seconds.

That wasn't worded too well.

The like query itself is quick to complete, as are the bug_id queries.

It's the joining of the LIKE query to the bug_id queries that causes the problem.

In isolation, all three components of the query execute quite quickly.

Comment 2 Jason McDonald 2015-09-25 04:20:41 UTC
It sounds like we need to try to undo some of the MySQL optimizations, or provide pg alternatives so that the code can go upstream.

Comment 3 Jason McDonald 2015-09-25 04:49:30 UTC
*** Bug 1264851 has been marked as a duplicate of this bug. ***

Comment 4 Jeff Fearn 🐞 2015-10-16 05:33:38 UTC
Moving this to 5.x as we need to change the way the middle query is run. If you fetch the bugs the same as the other two parts and present 3 bugs.bug_id IN statements then it's very fast. Intrusive change so should be postponed to after 5.0.

Comment 7 Jeff Fearn 🐞 2019-12-09 06:10:30 UTC
This is a search that times out in Production and takes 850 seconds to run on a dev system with timeouts disabled.

buglist.cgi?f1=keywords&f2=short_desc&f3=bug_group&j_top=OR&list_id=10602895&o1=casesubstring&o2=substring&o3=equals&query_format=advanced&v1=Regression&v2=bug&v3=redhat

Comment 8 Jeff Fearn 🐞 2019-12-09 06:42:53 UTC
Time          : 11.500512 seconds

That's just the SQL time, not bad given the search is pretty broad and returns over 200K results if allowed to, which is isn't!

Comment 9 Meiying Li 2020-02-27 06:44:28 UTC
Test environment:
https://bz-web.host.qe.eng.pek2.redhat.com

Steps to verify:
1. Timing the visit for page
https://bz-web.host.qe.eng.pek2.redhat.com/buglist.cgi?f1=keywords&f2=short_desc&f3=bug_group&j_top=OR&list_id=10609496&o1=casesubstring&o2=substring&o3=equals&query_format=advanced&v1=Regression&v2=bug&v3=redhat
Result:
It takes 22 seconds in qe instance, because this search is pretty broad with lots of data, so I can accept it.

Actual Result: PASS

Comment 11 Jeff Fearn 🐞 2020-04-01 12:20:16 UTC
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.


Note You need to log in before you can comment on or make changes to this bug.