Thanks Savio for help. Difference between yours and my result is probably beacuse of hardware. I'm trying on my laptop which is slower than your machine. But I can see that this is extremly bad performance because I tried similar in MS SQL 2008 database on the same laptop. I loaded those 130.000 x 96 records (I could only insert them all as rows so I got more than 12 million rows).
Equivalent query with TOP 1000 limit executed in* 50 ms* and query without limit which returned 30.000 rows executed in *500 ms.* And all that *without* date index! Also, there were no problems with memory overflow like in OrientDB. Actually, SQL Server memory usage stays below 600 MB with total of 12 databases some of which are larger than this one. Also, HASH index is not good because I also need range queries. Regards, Ivan. Dana utorak, 4. kolovoza 2015. u 15:08:46 UTC+2, korisnik SavioL napisao je: > > hi, > i tried your db, leaving everything as it is and making the query I got > this result: > > > > <https://lh3.googleusercontent.com/-Zp-no9vWfaQ/VcC2V3VyoyI/AAAAAAAAAFg/cnohdH-IFW0/s1600/sbtree.png> > > > > > > > > > > > > > > > > SBTREE > > > To speed it up you could delete the index of date and recreate it by > putting it as Type: NOT UNIQUE HASH INDEX (should be the fastest of all and > you can use it since there aren't ranges of queries). Putting this index > was 15% faster than the previous time, putting 2.775 seconds. This is the > result obtained: > > > > <https://lh3.googleusercontent.com/-Uo4-Jt9m26k/VcC4q6311iI/AAAAAAAAAF0/kA7Xn0NOA8g/s1600/hashindex.png> > HASH INDEX > > have you got some improvement? > > regards, > Savio L. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
