|There's more than one way to do things|
update: See last lines
I tried to repeat this performance by making an SQLite database of those two tables + indexes, together 600 MB, employees with 18M rows, groups with just 3 rows.
"select * from employees where sam_account_name = '<some unique value>'" takes 3 seconds. Your query takes even longer.
So, it seems your results are normal. SQLite is not a particularly fast database. (Then again, I know next to nothing of SQLite; it's always slow-ish in my hands so maybe I do something wrong.)
FWIW, postgres runs this same query in less than a millisecond, with the same data.
Could sqllitestudio be caching the query, or the data? It seems likely; sqllitestudio is just a wrapper, from what I read on its website.
How fast is a SQLite commandline query? Maybe you can try something like:
time sqlite3 ~/employee.db "select e.* from employees e, groups g where e.sam_account_name = g.sam_account_name and g.group_name = 'whatever' order by e.last_name, e.first_name"
(Sorry, I don't know the windows invocation.)
update: Mea culpa: I botched the indexing (didn't commit..), and with the indexes fixed it worked all right: fast, and just as fast as postgres. So I take all the above back.
update 2: now ran it on windows 7 too and it was PDQ there as well.
In reply to Re: DBD::Sqlite queries slow - and gives wrong results