Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.
03-07-2019 05:53 AM
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
Solved! Go to Solution.
03-11-2019 02:08 PM
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.
03-11-2019 08:14 AM
In either case for this kind of lookup you'd want an index present that covers the property in question. Try testing this way.
03-11-2019 08:17 AM
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.
03-11-2019 02:08 PM
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.
03-12-2019 02:22 AM
Interesting, thanks Andrew !
Is there a way to have a localDateTime without he nanoOfSecond ?
I might give a try to the ms timestamp then.
03-12-2019 08:55 AM
Sorry, it's built into the type itself, no way to go without it.
All the sessions of the conference are now available online