>> Indicies can be very >>> slow... may be the FTS4 table will be much faster for your queries. >> >> can you give more details about this concept ? what is the FTS4 table >> ? I am sorry don't know what is is !!! > > See > http://www.sqlite.org/fts3.html > The full-text index is very fast and scalable. You can use it instead of > a lot of btree-indicies when you can rewrite your search queries as FTS. >
Thanks for the pointer ,I did not notice this feature There may be one candidate for such feature but it 's not involved in our current performance problem ... >>> Did you try to use in-memory database as temp storage and >>> copy set of records into main database in single transaction? >> >> it's one of the goal of the benchmark but this solution has av ery >> high level of database corruption isn't it ..so I prefer to keep it as >> a joker... > > Database corruption can't be the result of the coping from temp in-memory > database to main disk-database! Could you give me more details about corruption cases ? Is there a list of contexts where we can get corrupted tables ? Thanks for all your answers regards jerome _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
