Hi Simon. > I have much love for FTS but it chews up storage space, processing power, and therefore battery life, something fierce. You may end up with a working app but your users will find it reduces their battery life to an hour.
Sounds unbelievable. Can you bring some example, please? In the past we worked for example on smartphone backup solutions, i.e. long running apps taking full processor power and writing a lot to SD cards (which in my opinion drains battery more), but did not observe such dramatic effect. (Or even worse battery "drainer": playing mp3 streamed over BT.) > Do you really need to /build/ an FTS database on a phone app ? Can you not (A) do what you want to do with GLOB and LIKE or (B) build the database externally before it's moved to the phone ? The app serves as a CRM client with full editing abilities, synchronization etc. Hence the data is live and cannot be pre-built. LIKE is used at the moment, but it has its perf limits as well. To prove it, here is a desktop benchmark: Desktop: W7, x64, Intel i5, 2.4 GHz 116 MB email table containing 10000 html-formatted emails. SELECT ... LIKE...'%xxx%'... command took 35.5 sec. (Producing 9 results) SELECT ... MATCH ... 'xxx*' command took 0.00 sec, i.e. somewhere between 0-7 msec. (By chance producing the same results) The funny thing was that the creation of the email FTS index took 22-23 sec, i.e. was faster than a single LIKE statement. ---------------------------- My plan is to implement FTS search as an optional feature: - Several FTS indexes grouped into multi-indexes (Example: people names may be in one of 3 tables: accounts, contacts, leads. These tables would contribute to PeopleSearch activity.) - FTS index is built on demand (when the user tries to use it) - The build procedure must be cancellable - Once built, the index will be maintained using triggers (for small data changes) - For large data changes (happens during synchronization when the server sends a lot of data) the FTS index is dropped Do you see any risks with this scheme? Jan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
