Hi, Can you please elaborate on this.
As far as I know the edges can not be indexed based on outgoing-vertex-properties. In this case the edges have no properties and could be light weight. Regards, -Stefan Regards, -Stefán On Tuesday, 12 May 2015 13:14:12 UTC, l.garulli wrote: > > Hi all, > I confirm that indexing the edges is the only way to have a O(1)-O(LogN) > time. Once indexed you can start from edges and get in/out vertices. > > > Best Regards, > > Luca Garulli > CEO at Orient Technologies LTD > the Company behind OrientDB > http://about.me/luca.garulli > > > On 12 May 2015 at 12:47, <[email protected] <javascript:>> wrote: > >> Hi, >> >> That is not applicable. Any "where clause" would demand the graph to >> visit all edges-vertexes even when looking for the newest 100 (to look up >> for the remote property). >> When there are 1 million+ edges that takes a very long time and is not >> acceptable. >> >> Thanks for playing! >> >> regards, >> -Stefan >> >> >> On Tuesday, 12 May 2015 07:54:03 UTC, Izzet Pembeci wrote: >>> >>> select out('ACTOR')[79220,79221,79222,79223,79224,79225,79226,79227, >>> 79228,79229,79230] from #140:0 >>> >>> Can you transform the above query to something like: >>> >>> select out('ACTOR') from #140:0 WHERE ... >>> >>> >>> If this works in a faster way, one may conclude that implementation of >>> [] has some performance problems. I also think that with your reasonable >>> bumps you earned yourself the right to open an issue on this one. >>> >>> iZzeT >>> >>> >>> On Monday, May 11, 2015 at 2:21:27 AM UTC+3, [email protected] >>> wrote: >>>> >>>> Hi, >>>> >>>> I do believe that in this case neither are applicable. >>>> I think the ridbag offers only traversal (not fetching by positions >>>> directly) and the edge has not property to index by (it's on the outgoing >>>> vertex). >>>> >>>> Regards, >>>> -Stefan >>>> >>>> On Sunday, 10 May 2015 15:25:18 UTC, Ziink A wrote: >>>>> >>>>> I'm still evaluating OrientDB so I might be totally off but I would >>>>> index the edge class (SOME_LABEL). >>>>> >>>>> Also take a look at http://orientdb.com/docs/last/RidBag.html >>>>> >>>>> >>>>> On Thursday, April 30, 2015 at 4:27:40 AM UTC-7, >>>>> [email protected] wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have very dense graph that contains vertexes with a lot of edges >>>>>> and I need to fetch the X last edges added to the Vertex. >>>>>> >>>>>> Orient SQL allows me to do it like this: >>>>>> >>>>>> - select out('SOME_LABEL')[80000] from #1:0 >>>>>> - please note that this is single direction (out) and a single >>>>>> link type / label ('SOME_LABEL') >>>>>> >>>>>> I have several questions regarding this: >>>>>> >>>>>> - Are the edges in a consistent order? >>>>>> - Assuming append-only operations and no deletions >>>>>> >>>>>> - Can anything be done to speed this up? >>>>>> - I ask because this query is very slow (0.7 sec.) >>>>>> - Asking for a list "select >>>>>> >>>>>> out('ACTOR')[79220,79221,79222,79223,79224,79225,79226,79227,79228,79229,79230] >>>>>> >>>>>> from #140:0" takes almost n*req_time longer >>>>>> >>>>>> - What happens underneath (is the whole list iterated from top to >>>>>> get to this) >>>>>> >>>>>> - Can this be achieved using the Java API? >>>>>> >>>>>> Assistance is highly appreciated. >>>>>> >>>>>> Best regards, >>>>>> -Stefan >>>>>> >>>>> -- >> >> --- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- --- 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.
