cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Timestamp vs localedatetime

neo4j
Node Clone

Hello everyone,

I would like to know, in terms of perfomance, which one is the most optimise query and if there is any drawback.

1551966636 <= this_one.date_as_a_timestamp <= 1551988636

or

localedatetime(yesterday)<= this_one.date_as_localedatetime <= localedatetime(tomorrow)

I currently use the localedatetime's one, with index, but I currently looking into some optimisation and I think date can be one to do.

Any help appreciated

1 ACCEPTED SOLUTION

The comparison would likely be a bit slower, simply because in the difference of the types. A ms timestamp is an 8 byte long (all of Neo4j's numeric values are 64-bit, despite the integer language in the docs), vs a 12-byte value for a localDateTime (8 byte epoch second + 4 byte nanoOfSecond). If you're trying to wring out whatever gains you can, then sticking with ms timestamps makes sense.

That said, this kind of choice would usually be made on ease of use. If all you need to do is raw comparisons and range lookups, then a timestamp works just fine. If you want easier access to inner time components, or make use of durations, then using the native temporal types makes more sense.

View solution in original post

5 REPLIES 5

In either case for this kind of lookup you'd want an index present that covers the property in question. Try testing this way.

Hi Andrew,

Thanks for the answer, It already has an index on the localdatetime.
It was more a question about internals, like if localdatetime comparison is slower that int comparison.

The comparison would likely be a bit slower, simply because in the difference of the types. A ms timestamp is an 8 byte long (all of Neo4j's numeric values are 64-bit, despite the integer language in the docs), vs a 12-byte value for a localDateTime (8 byte epoch second + 4 byte nanoOfSecond). If you're trying to wring out whatever gains you can, then sticking with ms timestamps makes sense.

That said, this kind of choice would usually be made on ease of use. If all you need to do is raw comparisons and range lookups, then a timestamp works just fine. If you want easier access to inner time components, or make use of durations, then using the native temporal types makes more sense.

Interesting, thanks Andrew !

Is there a way to have a localDateTime without he nanoOfSecond ?
I might give a try to the ms timestamp then.

Sorry, it's built into the type itself, no way to go without it.