Hi Artem,
Thanks for that workaround! Got it to work like this:
SELECT expand(*rids*) FROM (SELECT intersect(out('friends').@rid)* AS
rids*FROM [#11:589, #11:48780])
The issue also happens on the GratefulDeadConcerts database.
-- this returns no results:
SELECT expand(intersect(out('followed_by').@rid)) AS rids FROM [#9:3, #9:6]
-- this does:
SELECT expand(rids) FROM (SELECT intersect(out('followed_by').@rid) AS rids
FROM [#9:3, #9:6])
Regarding the "WHERE @rid IN" performance the query below over
GratefulDeadConcerts shows one case where the full table scan does happen:
EXPLAIN SELECT FROM V WHERE @rid IN (SELECT
intersect(out('followed_by').@rid) AS rids FROM [#9:3, #9:6])
{
"result": [
{
"@type": "d",
"@version": 0,
"projectionElapsed": 0,
"optimizationElapsed": 0,
"groupByElapsed": 0,
"current": "#9:808",
"fetchingFromTargetElapsed": 67,
* "documentReads": 811,*
"documentAnalyzedCompatibleClass": 809,
"recordReads": 811,
"elapsed": 75.75488,
"resultType": "collection",
"resultSize": 1,
"@fieldTypes":
"projectionElapsed=l,optimizationElapsed=l,groupByElapsed=l,fetchingFromTargetElapsed=l,documentReads=l,documentAnalyzedCompatibleClass=l,recordReads=l,elapsed=f"
}
],
"notification": "Query executed in 0.154 sec. Returned 1 record(s)"
}
That's the same behaviour I'm seeing on a distinct DB with 58K records
(with a noticeable slowdown).
Can this be a regression?
Thanks again!
Davide
On Mon, Apr 7, 2014 at 12:22 PM, Artem Orobets <[email protected]> wrote:
> Hi Davide,
>
> Looks like a bug. Could you provide a dataset where I can test expand
> issue.
>
> Meanwhile, you can try to use following workaround:
> SELECT expand() FROM (SELECT intersect(out('friends').@rid) FROM [#11:589,
> #11:48780])
>
> As for performance of your last query, you shouldn't be worried, such case
> is optimized to prevent full scan.
>
> I don't fully understand the performance hit. Is an index on @rid
>> necessary?
>
> rid is like a direct link to your record, you don't need to index it.
>
> Best regards,
> Artem Orobets
>
> * Orient Technologiesthe Company behind OrientDB*
>
>
> 2014-04-07 10:33 GMT+03:00 Davide Marquês <[email protected]>:
>
> Hi all,
>>
>> Looking for help on how to use the intersect operator correctly in a
>> query to grab information about mutual friends.
>> Note: using the latest development branch.
>>
>> The initial @rid intersection works as expected:
>> SELECT intersect(out('friends').@rid) FROM [#11:589, #11:48780]
>> {
>> "result": [
>> { "@type": "d", "@rid": "#-2:0", "@version": 0, "intersect": [
>> "#11:52266", "#11:52139", ..., "#11:49360" ], "@fieldTypes": "intersect=e" }
>> ],
>> "notification": "Query executed in 0.062 sec. Returned 1 record(s)"
>> }
>>
>> And this is the query I thought would work:
>> SELECT expand(intersect(out('friends').@rid)) FROM [#11:589, #11:48780]
>> Unfortunately, it returns no results. Bug? Misuse of expand over
>> intersect?
>>
>> This one works but at the expense of a full table scan:
>> SELECT FROM P WHERE @rid IN (SELECT intersect(out('friends').@rid) FROM
>> [#11:589, #11:48780])
>> I don't fully understand the performance hit. Is an index on @rid
>> necessary?
>>
>> Tips/references to open issues welcome.
>>
>> Cheers,
>> Davide
>>
>> --
>>
>> ---
>> 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.
>>
>
> --
>
> ---
> 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.
>
--
---
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.
