Hi Wouter, Would it be possible to create an index over multiple classes including the > relations or something like that?
No, automatic indexing over multiple classes is not supported. You can try to play with a composite index over in_ARTICLE_SUPP_NR and other field and do select from article instead of traverse, but that possible only if you have lightweight edges. Best regards, Artem Orobets * Orient Technologiesthe Company behind OrientDB* 2014-06-10 11:47 GMT+03:00 Wouter de Vaal <[email protected]>: > Hi Artem, > > Thanks, I thought as much. > > One approach for us would be to denormalize data, but I am looking if > there exists a way where I wouldn't need to maintain multiple > classes/indexes for this to work. > Would it be possible to create an index over multiple classes including > the relations or something like that? > > Thanks, > Wouter > > Op dinsdag 10 juni 2014 10:34:03 UTC+2 schreef Artem Orobets: >> >> Hi Wouter, >> >> It is not really that easy to improve performance of subquery with index. >> Because in a sub-query you select records from subset created somehow but >> not from class. >> >> General approach in this case is to rewrite your query in more efficient >> way, change schema or create a manual index. >> Certain advises need more detailed investigation of your case. >> >> Best regards, >> Artem Orobets >> >> * Orient Technologiesthe Company behind OrientDB* >> >> >> 2014-06-10 10:22 GMT+03:00 Wouter de Vaal <[email protected]>: >> >>> Hi, >>> >>> We have an ARTICLE -> SUPPLIER -> COUNTRY database, with loads of >>> ARTICLE records, quite a few SUPPLIER records and some COUNTRY records. >>> Now if we want to filter on articles with a supplier in a certain >>> country we can do this fast enough by querying like this: >>> >>> select from (select expand(in('ARTICLE_SUPP_NR')) from (select >>> expand(in('SUPP_COUNTRY')) from COUNTRY where _id = 'NL')) >>> >>> But if we want to filter on the ARTICLE table, or count something, >>> things get slow as there are a lot of results (about 80K) and it looks like >>> orientdb is not using any index created on the ARTICLE table. >>> >>> Question is, can orientdb be quering in a way that indexes are used on a >>> subquery result? So my subquery would result in a bunch of expanded ARTICLE >>> rows, could filtering/sorting/counting on that result be executed on an >>> index somehow, so we still get good performance? >>> >>> Thanks, >>> Wouter >>> >>> >>> -- >>> >>> --- >>> 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.
