views:

459

answers:

2

Hi,

we're writing a scientific tool with MySQL support. The problem is, we need microsecond precision for our datetime fields, which MySQL doesn't currently support. I see at least two workarounds here:

  • Using a decimal() column type, with integer part corresponding to seconds since some point in time (I doubt that UNIX epoch will do, since we have to store measurements taken in 60's and 50's).
  • Using two integer columns, one for seconds, the other one for microseconds.

The most popular query is selecting columns corresponding to a time interval (i.e. dt_record > time1 and dt_record < time2).

Which one of these methods (or perhaps another one) is likely to provide better performance in the case of large tables (millions of rows)?

+3  A: 

If you say that the most popular queries are time base, I would recomend going with a single column that stores the time as in your first option.

You could pick your own epoch for the application, and work from there.

This should simplify the queries that needs to be written when searching for the time intervals.

Also have a look at 10.3.1. The DATETIME, DATE, and TIMESTAMP Types

However, microseconds cannot be stored into a column of any temporal data type. Any microseconds part is discarded. Conversion of TIME or DATETIME values to numeric form (for example, by adding +0) results in a double value with a microseconds part of .000000

astander
A: 

How about splitting the date parts into a date-only part, and microseconds from midnight? There are less than 2^64 microseconds in the day. Then cluster the table on {date, microsecond}.

I would guess, though I don't know your data, that certain queries would be fine with day-level accuracy -- 'experiments in 1964' doesn't need to worry about microseconds.

Steve Cooper
Typical queries will require minute-level precision for a start, which means that the query will need to use two columns in its where clause, which, as far as I understand, will noticeably affect performance.
David Parunakian