Confirmed users
764
edits
Firefox/Projects/FTS and Awesomebar: Difference between revisions
Jump to navigation
Jump to search
→Status: Updated status, on hold for now
(→Intro: Remove paragraph on i18n from the Intro, since that's really not the goal) |
(→Status: Updated status, on hold for now) |
||
| Line 13: | Line 13: | ||
== Status == | == Status == | ||
ON HOLD | |||
==== 2010/04/07 ==== | |||
After a few weeks of exploration, it's not clear as I had hoped it would be that FTS can provide faster awesomebar searches on the desktop. The awesomebar's default SQL query (one of several it performs) makes good use of indexes, and while I don't fully understand why, its execution seems to take constant time independent of data set size. Prefix searches with FTS are slow; to mitigate, I investigated partitioning the FTS table into many tables, each containing no more than 1000 rows. Individual table lookups were fast with this scheme, but the overhead of searching dozens of tables conspired to make the aggregate query slower than the awesomebar's default query. Perhaps there is a way to game this tradeoff between partitioning and overhead that more tinkering would reveal. | |||
There may be other areas of Firefox where FTS can help -- search terms in the Places query API, for example. | |||
On hold for now. | |||
==== Week of 2010/03/15 ==== | ==== Week of 2010/03/15 ==== | ||