On 16 Jul 2009, at 6:22pm, MADHAVAN VINOD wrote:

> Suppose, if I don't have index, is this the desired behavior of Sqlite
> to take this much time to fetch just 10 records or am I missing
> something here.

Your first post states quite clearly '5) No INDEX created.'.  Without  
any index on your table, how else could the computer do the SELECT  
command ?

I think you don't know what indexes are for, and you haven't thought  
through the task you are giving the computer.  It may be that at this  
stage you should stop programming and read some books on how database  
systems work, to understand how best to use indexes.  If there are no  
useful indexes on your table, the computer has to read every row of  
the table to find out which rows satisfy your SELECT command.  It then  
has to work out which rows satisfy your 'WHERE' clause, and then sort  
the rows it doesn't reject into the right order.  Naturally this takes  
a lot of time.

The whole idea of indexes is to allow your computer to quickly find  
which rows it needs without having to read every single row.  So  
ideally you define an index which lets it select the right records in  
the right order without having to read any data from the table.  Your  
problem is this: you write in your original post

'So my WHERE clause is like  "CurrTime <= ExpireTime AND CurrTime >=
NextProcessingTime AND a=1 AND b < c"'

I am going to assume that all of 'CurrTime', 'ExpireTime',  
'NextProcessingTime', 'a', 'b', 'c' are fields in your table.

Your next problem is that you use, for example, 'b < c' in your SELECT  
command so you are asking for a test to done for every row in the  
table to decide if the row should be considered for the SELECT  
command: each time you do a SELECT command it has to read every row in  
the table and check to see whether 'CurrTime <= ExpireTime', 'CurrTime  
 >= NextProcessingTime', and 'b < c'.  Since you say you have 100,000  
that's 100,000 read instructions and 300,000 pieces of mathematics it  
has to do every time you do your SELECT command.  The idea of indexes  
is to have as much of possible of that done when the record was saved  
in the first place, so it doesn't have to be done every time you use a  
SELECT command.

If 'CurrTime' is a column of your table you could calculate all of  
your WHERE clause when you write each record and write the result into  
another column of the table, then index that column.  If it isn't,  
then you should certainly provide an index on ExpireTime or  
NextProcessingTime or 'a', whichever one allows the SELECT to reject  
the most records most quickly.  And with a good understanding of the  
data in your table you could make up an compound index that makes the  
SELECT work even faster.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to