> I can't solve your problem but I have observations. I don't see how any SGDB > (or RDBS as we call them) could do this quickly without lots of indexes. >
but they do :( Firebird for exemple ... > Your long SELECT command is something I would probably do in my programming > language instead of SQLite. Just read every record and do the 'ifs' in my > language. I think this would actually be as fast or faster than having > SQLite do it. > yes but we speak about millionS of rows :( > But there are ways to make SQLite do it quickly. Either way you have to read > every record, so there's no way to save time there. Another way to do it > would be to add a column to your HASH table. Let's call it 'tally'. You > would start by doing > > UPDATE HASH set tally = 0; > > Then you would do 25 UPDATE commands like > > UPDATE HASH SET tally = tally + 1 WHERE x1_y1 BETWEEN #randomnumber1 AND > (#randomnumber1 + 20); > [...] > UPDATE HASH SET tally = tally + 1 WHERE x3_y2 BETWEEN #randomnumber34 AND > (#randomnumber34 + 20); > [...] > UPDATE HASH SET tally = tally + 1 WHERE x5_y5 BETWEEN #randomnumber73 AND > (#randomnumber73 + 20); > > Then to find the records which obeyed all 25 limits you'd do > > SELECT id FROM HASH WHERE tally = 25; > yes but not really a "multri thread" solutions :( > If you put 26 indexes on the table (one on each x_y and one on tally) this > should execute really quickly. It might be faster still if you make another > table just for the 'tally' column. but the row returning by just the 5 index is already zero :( so how adding more index can help ? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
