I just want to do a quick check if it is acceptable to have timestamps of different precision within one measurement of a database. As far as I can tell influx does not care (see screenshot). I have a database full of unnecessary nanosecond precision timestamps and I am looking at now writing to it with at most microsecond precision, maybe just millisecond.
I made another set of data and clearly there is something goofy going on here. Look at the second to the last timestamp, it is out of order.
> select * from test order by desc
name: test
time I V channel
---- - - -------
1573021026234907413 3.8 4 chX
1573021026232929357 3.8 4 chX
1573020045720970407 3.6 4 chX
1573019798465784892 3.2 4 chX
1572997626338334200 3.8 4 chX
157299762633833400 3.7 4 chX
1572997626338334 3.8 4 chX
1573019470355 3.2 4 chX
1572997626338 3.8 4 chX
Also, if I try to select by time, it only selects the nanosecond times:
> SELECT * FROM test WHERE time > now() - 10h order by desc
name: test
time I V channel
---- - - -------
1573021026234907413 3.8 4 chX
1573021026232929357 3.8 4 chX
1573020045720970407 3.6 4 chX
1573019798465784892 3.2 4 chX
1572997626338334200 3.8 4 chX
I’m not totally sure why the results are out of order on these responses–I couldn’t recreate the issue. That being said, it’s generally bad practice to have multiple time precisions in the same measurement because it can lead to confusion like this. I’ll see if I can dig deeper into this behavior, butour recommendation is to try to keep things at the same time precision.
The timestamps are not out of order. They are all recorded as nanosecond precision and Influx has “helpfully” left-aligned the timestamps. If you right-align them you’ll see that they are listed correctly.
If you want measurements to be logged with one-second precision you would need to specify that precision when writing the measurement, or pad on the right with 0s (multiply by 10^6) before writing the measurement with nanosecond precision.
