On Sun, 5 Dec 2010 19:08:59 -0500, "Igor Tandetnik" <itandet...@mvps.org> wrote:
>Kees Nuyt <k.n...@zonnet.nl> wrote: >> If you need a compound index for performance reasons, you can use >> the autoincrement key as the primary key for the table and define a >> unique index on the compound key. > > I can't think of any statement that would run faster > if you, in addition to an existing unique index on A, > also create one on (A, B). > Am I missing something obvious? You're right. I was thinking about both A and B in a WHERE clause, but indeed, a value for B wouldn't make the search more specific. Then we have the case when the WHERE value for A exists, but the one for B doesn't, and even there it doesn't help, except the mismatch for B only needs the index lookup, not the indirection to the table. But then again, with A defined as integer primary key autoincrement, the table itself is the index so there is no indirection. So, you didn't miss anything obvious, I was missing something not completely obvious at first sight ;) -- ( Kees Nuyt ) c[_] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
