| 2010-07-20 20:40:51 |
Robert Collins |
bug |
|
|
added bug |
| 2010-07-25 09:04:11 |
Robert Collins |
tags |
fti oops search timeout |
fti search timeout |
|
| 2010-08-10 04:00:50 |
Robert Collins |
summary |
timeouts on Distribution:+bugs doing searches |
Distribution:+bugs search timeout due to package name matching |
|
| 2010-08-10 04:07:29 |
Robert Collins |
tags |
fti search timeout |
search |
|
| 2010-08-10 04:07:41 |
Robert Collins |
summary |
Distribution:+bugs search timeout due to package name matching |
Distribution:+bugs search has worrying overhead due to package name matching |
|
| 2010-08-10 04:08:57 |
Robert Collins |
description |
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= |
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
|
|
| 2010-08-15 20:44:17 |
Robert Collins |
description |
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
|
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
Distribution:+filebug-show-similar is also showing up as a slow performer in the PPR and this may have the same root cause.
|
|
| 2010-08-15 20:47:57 |
Robert Collins |
description |
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
Distribution:+filebug-show-similar is also showing up as a slow performer in the PPR and this may have the same root cause.
|
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
Distribution:+filebug-show-similar is also showing up as a slow performer in the PPR and this may have the same root cause (see bug 618380)
|
|
| 2011-02-06 22:42:16 |
Robert Collins |
launchpad: importance |
High |
Critical |
|
| 2011-02-06 22:42:22 |
Robert Collins |
tags |
lp-bugs search |
lp-bugs search timeout |
|
| 2011-02-14 04:53:00 |
Robert Collins |
branch linked |
|
lp:~lifeless/launchpad/bug-607960 |
|
| 2011-02-15 12:00:47 |
Launchpad QA Bot |
launchpad: milestone |
|
11.03 |
|
| 2011-02-15 12:00:47 |
Launchpad QA Bot |
launchpad: assignee |
|
Robert Collins (lifeless) |
|
| 2011-02-15 12:00:48 |
Launchpad QA Bot |
tags |
lp-bugs search timeout |
lp-bugs qa-needstesting search timeout |
|
| 2011-02-15 12:00:50 |
Launchpad QA Bot |
launchpad: status |
Triaged |
Fix Committed |
|
| 2011-02-15 18:34:36 |
Robert Collins |
tags |
lp-bugs qa-needstesting search timeout |
bad-commit-12374 lp-bugs qa-needstesting search timeout |
|
| 2011-02-15 19:01:45 |
Robert Collins |
description |
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.edge.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
Distribution:+filebug-show-similar is also showing up as a slow performer in the PPR and this may have the same root cause (see bug 618380)
|
The big problem is the ILIKE '%foo%' substring search on BugTask.targetnamecache. On production, it consistently takes a little over a second. At the moment, we don't have infrastructure to do substring searches against this much data quickly enough so if we need a quick fix we need to drop this clause, relying on the full text query.
If we can't drop this clause, we will need a new index type like Wildspeed (http://www.sai.msu.su/~megera/wiki/wildspeed -- written by the same people who wrote tsearch2), trigrams (in postgresql-contrib), or NIH it and roll our own using a pair of tables and standard indexes for prefix searches and more complex queries.
This was originally filed as a fti bug, but was largely a dupe/operational issue; the discussion is worthwhile though in the context of ILIKE, so I've repurposed the bug to keep that discussion handy.
https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1662EA433
SQL time: 13899 ms
Non-sql time: 646 ms
Total time: 14545 ms
Statement Count: 29
https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=libbluray&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
Distribution:+filebug-show-similar is also showing up as a slow performer in the PPR and this may have the same root cause (see bug 618380) |
|
| 2011-02-15 19:46:43 |
Robert Collins |
tags |
bad-commit-12374 lp-bugs qa-needstesting search timeout |
bad-commit-12374 lp-bugs qa-ok search timeout |
|
| 2011-02-16 02:04:18 |
William Grant |
launchpad: status |
Fix Committed |
Fix Released |
|
