Hi Jon,
It seems correct, there is no additional ORDER BY in the execution plan and
the fetch from index is correct, so I'd say the problem is probably related
to the index size or to some caching.
In general, I'd say you can expect the performance to remain more or less
constant around these valu
Hi Luigi,
for query:
SELECT FROM ANYVERTEX WHERE date < 999 ORDER BY date DESC LIMIT
3
please find the describe below.
+ FETCH FROM INDEX ANYVERTEX.date_targetId
date < 999
+ EXTRACT VALUE FROM INDEX ENTRY
filtering clusters [95,96,94,97,98,87,75,79,80,77,78,76,91,9
Hi Jon,
Could you please post an EXPLAIN of that query?
Thanks
Luigi
Il giorno mar 7 mag 2019 alle ore 11:23 'Jon' via OrientDB <
orient-database@googlegroups.com> ha scritto:
>
> Hi Luigi,
>
> thanks for your fast reply. I' am doing performance tests in OrientDB
> 3.0.18 locally and 3.0.3 in
Hi Luigi,
thanks for your fast reply. I' am doing performance tests in OrientDB
3.0.18 locally and 3.0.3 in our test environment. The index type is
UNIQUE(SBTREE). The index is a composite key composed of an id and the
timestamp. From the logs I can definitely confirm that the query above
tak
Hi Jon
Using an index should definitely solve the problem, so it's strange that it
didn't work in your case.
Which OrientDB version are you using? And what kind of index did you define?
Thanks
Luigi
Il giorno lun 6 mag 2019 alle ore 13:44 'Jon' via OrientDB <
orient-database@googlegroups.com> h
Let's say I have the following list of vertices (connected by edges) in the
orient database:
[t=1] --> [t=2] --> [t=3] --> [t=4] --> [t=5] --> [t=6] --> [t=7]
Each vertex has a timestamp t. I now want to receive the last vertex before
a given date. Example: give me the last vertex before
