Fabian Giesen wrote: > Simon Slavin wrote: ... >> Also, store your time as a numeric value (Unix epoch or Julian day) rather >> than a string. Numbers are faster to handle than strings. INTEGERs are >> faster to handle than REALs. > > > :-) > > The time fields are 64-bit ints. The exact meaning depends on the > capture target platform (we support several) but usually it's either > a system-synchronized CPU clock cycle counter (when available) or > ticks for a high-frequency bus/event timer.
It's worth adding that SQLite stores integers in variable length (from 1 to 9 bytes). Small integers are more compact to store and are thus more efficient (both in the table and in its indexes). So if you can store numbers relatively to a known minimum values, you can make records smaller. See: http://sqlite.org/src4/doc/trunk/www/varint.wiki Multiple indexes are independent from each other. So it would be nice if creation of multiple indexes could be done in parallel (one thread per index). That's assuming that creation of indexes is CPU bound and not I/O bound. Regards Dominique _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
