Hi Eric,
In a schemaless/mixed schema it's hard to make assumptions, but something
can be optimized of course.
Probably the big part of the difference is due to the number of traversed
edges (N at the first level, NxN at the second, probably), but part of that
can also be due to internal mechanisms of the ODocument structure (eg.
management of reference trees for save) that in this case could be avoided.
We'll do some profiling on this, I'll let you know
Thanks
Luigi
2016-11-30 16:05 GMT+01:00 Eric24 <e...@24x8.com>:
> @Luigi--
> Hmmm. If the difference between traverse out('MyEdge') and
> out('MyEdge').out('MyEdge') is 100X, that sounds like an opportunity for an
> internal optimization. Unless there are dozens of other edges beyond the
> first level in this schema, it seems that the query optimizer could figure
> this out up-front. Thoughts?
> --Eric
>
> On Tuesday, November 29, 2016 at 12:39:37 PM UTC-6, Tomas Aftalion wrote:
>>
>>
>> Thank you Luigi, it did help. Also, when using directly, for example,
>> out('MyEdge').out('MyEdge') speeds things up considerably ~100x.
>>
>> Best,
>> Tomas
>>
>>>
>>> --
>
> ---
> 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 orient-database+unsubscr...@googlegroups.com.
> 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 orient-database+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
