Confirmed users
764
edits
Firefox/Projects/FTS and Awesomebar: Difference between revisions
→Status
m (→Intro) |
(→Status) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
SQLite supports indexed full text search (FTS) through its fts extensions. Indexed FTS makes text searches fast: Rather than looking at every record in the database to see if it contains a search string, target records are found by comparing the search string against an index. | SQLite supports indexed full text search (FTS) through its fts extensions. Indexed FTS makes text searches fast: Rather than looking at every record in the database to see if it contains a search string, target records are found by comparing the search string against an index. | ||
A good first target feature is the awesomebar. It is highly visible, and since it makes extensive use of text searches, it stands to benefit from this work. | A good first target feature is the awesomebar. It is highly visible, and since it makes extensive use of text searches, it stands to benefit from this work. | ||
Note that full text search does not mean that we store the entire text of pages. We will use it to store page titles, URLs, tags, etc., as we already do now, only lookup will be fast. | (Note that full text search does not mean that we store the entire text of pages. We will use it to store page titles, URLs, tags, etc., as we already do now, only lookup will be fast.) | ||
* Champion, lead: adw | * Champion, lead: adw | ||
| Line 15: | Line 13: | ||
== Status == | == Status == | ||
STALLED, GOING DOWN, PEOPLE SCREAMING | |||
==== 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 ==== | ||