On Thu, 2013-11-28 at 12:19 +0000, Simon Slavin wrote:
> On 28 Nov 2013, at 11:22am, Tristan Van Berkom <trista...@openismus.com>
> wrote:
>
> > Yes, I definitely agree that on a conceptual level, I should not
> > have to consider the pre-optimization of my own query before
> > launching it. As a functional language, I should only have to
> > describe the query and let SQLite do a better optimization.
>
> While you're concerned about optimization, you might look at your column
> definitions. For instance, you are storing email addresses in a column.
> Since email addresses are not case sensitive you might want to define this
> column as
>
> COLLATE NOCASE
>
> This will mean that any indexing on this column will ignore case, and any
> comparisons of text with text in this column will ignore case by default. It
> can simplify all other SQL statements that refer to that column.
>
That's not an issue, our matching API is completely case insensitive,
and all data which we insert into columns for searches is normalized
in advance (excepting the vCard UID field)... or normalized and reversed
in the case we configure for quick suffix matching.
Thanks for the tip anyway, though :)
Cheers,
-Tristan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
