Closed
Bug 500290
Opened 15 years ago
Closed 1 year ago
Re-engineer PlacesSQLQueryBuilder class, to build more optimized queries, joining least number of tables
Categories
(Toolkit :: Places, defect, P3)
Toolkit
Places
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mak, Unassigned)
References
Details
(Keywords: perf)
Actually URI queries need to join historyvisits only to apply some filtering, but there are common paths that do not even require to be aware of all visits. Joining with all visits can be really slow, and we should do that only if we really need to use those visits data. We should flatten most useful data to moz_places, we already have visit_count, frecency, last_visit_date, hidden, typed... we could have an is_redirect field for example, and is session really useful (we don't use it really, and is not a commonly appreciated feature). That would cover vast majority of our needs, we would only need to use historyvisist when we have to query by date or by visit_type, or we need to update moz_places values, or we have a VISIT query. If this would be possible, many queries would be no more dependent on size of history, and faster.
Reporter | ||
Updated•15 years ago
|
Summary: Investigateremoving the need to join historyvisits for URI grouped queries → Investigate removing the need to join historyvisits for URI grouped queries
Reporter | ||
Comment 1•15 years ago
|
||
morphing bug a bit: best thing would be to split out placesSQLQueryBuilder to a separate source file, and re-engineer it so that it will be able to build really optimized queries based on actual query options.
Summary: Investigate removing the need to join historyvisits for URI grouped queries → Re-engineer PlacesSQLQueryBuilder class, to build more optimized queries, joining least number of tables
Reporter | ||
Updated•7 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
Reporter | ||
Comment 2•1 year ago
|
||
I'm marking the bug as wontfix, not because it's not something we want to do, but because we are unlikely to make this kind of change to the existing querying code. We should refactor, or even rewrite, the querying API and consider performance of batch results from the beginning, doing as much as possible in SQL.
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•