danjenkins wrote: > > Hello, > We use a julian.decimal format to represent date/time (i.e. noon of August > 26, 2009 would be 40049.5000) and we use this julian date for an index > key. Our databases are frequently up to 3GB in size containing 10 million > records with 15 assorted field types per record and contain 6 months of > data. I'm proposing to break up the julian.date into two separate > integers for the data and time and index off the date integer. > > Of course this change will give queries some sort of a speed boost, but by > how much would you think? > > Many thanks, > Dan I think it's better to try go with single integer. It perfectly fits range 12:00:00 midnight, January 1, 0001 Anno Domini (Common Era) to 11:59:59 P.M., December 31, 9999 A.D. (C.E.) in 100 nanosecond units. And it's good idea to store all dates in UTC.
Why do you need second integer? You can have even a bit better performance (due to smaller size of index) in case you will use lower precision 1 second instead of 100 nanoseconds or shorter date range (i.e. number of seconds since 1/1/1900 00:00) Float value will always take 8 bytes to store, integer will depend from the size of value. Compound index will be slower than single. ----- Best Regards. Max Kosenko. -- View this message in context: http://www.nabble.com/Index-performance-using-2-integers-vs.-1-float-tp25165036p25170683.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
