-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
$long index #39
Comments
Hi Jaromir, thank you for kind words! $long index should be relatively easy to implement and I would expect it's performance to be inline with "int". I'll have a look at doing this today. This would be a patch on 2.1.0. Cheers, |
Hi Alex, that would be great! Thanks a lot. Btw: I've been looking at road map of your project and I am quite excited about the next release. Is there any ETA? Cheers, |
I don't have ETA unfortunately, but I'm working on getting to release stage as hard as I can. There are quite a few sharp edges yet to be covered. Cheers, |
I have pushed 2.1.1-SNAPSHOT to maven central. Please have a look if this is what you need? |
Hi Vlad, thanks a lot for this. I've tested the new $long index and it is almost as fast as $int index. Much appreciated. Jaromir |
Hi Jaromir, no problem :) |
Hi Jaromir, latest snapshot now also support index on long fields. In addition to storing data as you would in 2.0 you can query your storage using much more evolved SQL system. Let me know if i can be of any more help with this issue. |
Hi Vlad, thanks a lot - much appreciated. Just a quick question: is nfsdb now called On Sun, Sep 4, 2016 at 5:06 AM, Vlad Ilyushchenko notifications@github.com
|
Hi Jaromir, yes, i renamed nfsdb to questdb some time ago. It is an evolution of the same code base. It has some API compatibility, but binary files are different. |
Hi Vlad,
Once again, thanks for your work on NFSdb - I am looking forward to the next release.
Quick question: Are you planning to add support for 64bit integer index? Current version (2.1.0) supports only $int and $str. I currently use $int but I am afraid that 32bit integer range won't be enough for me in the near future. I was thinking of using $str instead. I've tested performance of $int vs $str: (using an object with int/string key + 80bytes of raw data). These are results of my testing:
Int key:
5,000,000 items added in 315ms
Lookup time is 37ms
String key:
5,000,000 items added in 616ms
Lookup time is 38ms
The lookup time is almost the same, but append time is approximately two times slower - that is why I decided not to use $str.
What do you think?
Thanks,
Jaromir
The text was updated successfully, but these errors were encountered: