Re: [orientdb] compound index seems to be ignored
Hi, I've attached the database export, including the defined index. And here's the query: SELECT @rid FROM User WHERE state=active AND birthdayYear = 1994 AND birthdayYear = 1958 AND ageMin = 59 AND ageMax = 59 AND height = 176 AND height = 161 AND heightMin = 188 AND heightMax = 188 AND relationship IN [free] AND theirRelationship IN [free, doesntMatter ] AND lookingFor IN [relationship] AND theirLookingFor IN [relationship, doesntMatter ] AND @rid NOT IN [#12:0] Thank you for conducting this test. Best regards, Mate On Friday, March 6, 2015 at 9:37:19 AM UTC+1, Luigi Dell'Aquila wrote: Hi, A small sample database and the query you execute will be enough Thanks Luigi 2015-03-05 21:18 GMT+01:00 Máté Gábri gabr...@gmail.com javascript:: Hi Luigi, sorry I'm new to this so please forgive my noob question. What should I provide so that you can test it? My code (nodejs) I'm using for testing, or some test data with the query and index I'm using? Best regards, Mate On Thursday, March 5, 2015 at 10:51:26 AM UTC+1, Luigi Dell'Aquila wrote: Hi Mate, there are no limitations in the number of properties that can be indexed, so there must be a bug somewhere. Could you provide a test case to reproduce it? Thanks Luigi 2015-03-04 22:25 GMT+01:00 Máté Gábri gabr...@gmail.com: Hi, I'm trying to get familiar with OrientDB's indexing to make some performance tests. I'm running a query on a class which uses 10+ conditions in the WHERE statement with range selections, constants and IN conditions. I've created the compound index in the same order as the fields appear in the WHERE statement but it seems like the index is ignored. The EXPLAIN command shows that the index is used, but the scanned documents number is the same as the number of documents in the class. After some experimentation I came to the conclusion that with 2 conditions the index is working, so just part of the class is scanned, but after adding the third condition the whole class is scanned. I'm just not sure wether this is normal behaviour or not. Am I missing something? Best regards, Mate -- --- 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-databa...@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-databa...@googlegroups.com 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. test.json.gz Description: Binary data
[orientdb] Re: Adding edges with properties after using Document API
Well, with either approach you're actually using the Graph API once you start using the OrientGraph object. A Vertex (OrientVertex) is built on top of a document, and its ODocument can be obtained by calling vertex.getRecord(). But an ODocument is not a Vertex. By working with OrientVertex objects, you essentially get the best of both worlds. If you don't need the automatic management of links, then ODocument is just fine. -Colin Orient Technologies The Company behind OrientDB On Friday, March 6, 2015 at 5:04:43 AM UTC-6, Christian C wrote: Actually the better approach for me is to stick with the document api and do like so: ODatabaseDocumentTx db = pool.acquire(); OrientGraph g = new OrientGraph(db); Out of interest is the a way to cast ODocument to Vertex and vice versa? PS Would be nice if you could provide a one liner in the wiki for the Document API and for the Graph API how to get the otherone. This my help new commers a lot. -- --- 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.
Re: [orientdb] No index use when using sub query
Luca, So I'll try and give you a full test case early next week. But basically what I'm having trouble with is that its fine to put a index on the sub query and that will make that part faster. But if the sub query were to return 3000 rows the outer part of the query (where foo = bar) will never use the index on 'foo', and becomes very slow +1second. I'll give you a full test case next week, however given an index on 'foo' and 'status' should that query be fast? Or am I misunderstanding something? Thanks, Jamie On 6 Mar 2015 16:38, Luca Garulli l.garu...@gmail.com wrote: Hi Jamie, To speed up the query like: select from (select expand(in()) from User where status = 'active') where foo = bar LIMIT 10 You should have an index on User.status to avoid scanning all User. Can you elaborate more the query that is slow? Lvc@ On 5 March 2015 at 22:28, Jamie Blair jamie.bl...@gmail.com wrote: Luca, So I had problems with this approach if I needed to select on a larger collection rather that a single rid. So something along the lines of select from (select expand(in()) from User where status = 'active') where foo = bar LIMIT 10 I ran into problems I'm assuming I'm not quite think in the correct way. Also I know I could put a limit on in inner query also but that would mean that I could potentially end up with less than the required number of results. Hope that makes sense Thanks for the help, Jamie On 5 Mar 2015 19:48, Luca Garulli l.garu...@gmail.com wrote: Hi Jamie, First, OrientDB supports direct loading by RID at O(1) cost. So this: SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, #23:80708, #23:70291] Can be translated to: *SELECT FROM [#23:83354, #23:366, #23:99933, #23:80708, #23:70291]* That is MUCH faster. Don't put indexes on RIDs: RIDs are physical positions and are the reason why OrientDB is so fast on traversing and direct loading by RID. Then, in this query you're thinking relational: SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out IN #27:819) Try this (it should take few ms): *SELECT expand(in()) FROM #27:819* If you want to filter by vertex's properties you can do: *SELECT FROM (* * SELECT expand(in()) FROM #27:819) WHERE age = 18* Lvc@ On 3 March 2015 at 11:42, Jamie Blair jamie.bl...@gmail.com wrote: Luigi, Thanks, but there is an extra part to our problem as soon as we want to put conditions on the Vertex we can't. So for our use case we have a lucene index on the Vertex:name, I've found the expand to not be very useful because it kind of backs me into a corner with adding conditions to my query. Is there a list of the current issues with the query optimizer anywhere? Also if anybody could give me an example of how I would also add a lucene condition to the above query that'd be greatly appreciated Thanks, Jamie On Tuesday, March 3, 2015 at 7:21:34 AM UTC, Luigi Dell'Aquila wrote: Hi Jamie, yes, the right thing to make it faster is this: select expand(inV()) FROM SomeEdge WHERE out IN #27:819 Currently there are no work arounds for that at parser level. The problem is not tracked as a single issue because it's a wide topic, and it's being addressed as a full development process, but if you want you can create a specific issue for this Regards Luigi 2015-03-02 18:11 GMT+01:00 Jamie Blair jamie...@gmail.com: Luigi, Have you any idea how I would make this fast, or is there a work around for the present query optimizer? Also is there a ticket I can track in github for this? Thanks, Jamie On Monday, March 2, 2015 at 4:55:51 PM UTC, Luigi Dell'Aquila wrote: Hi Jamie, this is a known issue, we are working hard on the new query parser and executor and one of the main goals of all this is query optimization. Thanks Luigi 2015-03-02 17:11 GMT+01:00 Jamie Blair jamie...@gmail.com: The following query returns a set of `@rid` and completes in about `0.012sec` SELECT in FROM SomeEdge WHERE out IN #27:819 Now if I were to select from another Vertex using those `@rid`s in there literal form, this would take a very long time and I get a timeout (above 4seconds). I'm presuming its scanning over all the entries SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, #23:80708, #23:70291] Interestingly enough if I were to use a single `@rid` rather than a set it would be fast. So I'm assuming the query optimizer has the scope to go a little further and also optimize multiple results SELECT FROM SomeVertex WHERE @rid in [#23:83354] But not to worry because I can make this faster by adding an index to `SomeVertex.@rid` so now this is fast again CREATE INDEX foo on SomeVertex (@rid) unique SELECT FROM SomeVertex WHERE @rid in [#23:83354,#23:366,#23:99933,# 23:80708,#23:70291] But if I compose the 2 queries, I'd expect this to be fast, but it's still slow and causes timeout (above 4 seconds)
Re: [orientdb] No index use when using sub query
Hi Jamie, To speed up the query like: select from (select expand(in()) from User where status = 'active') where foo = bar LIMIT 10 You should have an index on User.status to avoid scanning all User. Can you elaborate more the query that is slow? Lvc@ On 5 March 2015 at 22:28, Jamie Blair jamie.bl...@gmail.com wrote: Luca, So I had problems with this approach if I needed to select on a larger collection rather that a single rid. So something along the lines of select from (select expand(in()) from User where status = 'active') where foo = bar LIMIT 10 I ran into problems I'm assuming I'm not quite think in the correct way. Also I know I could put a limit on in inner query also but that would mean that I could potentially end up with less than the required number of results. Hope that makes sense Thanks for the help, Jamie On 5 Mar 2015 19:48, Luca Garulli l.garu...@gmail.com wrote: Hi Jamie, First, OrientDB supports direct loading by RID at O(1) cost. So this: SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, #23:80708, #23:70291] Can be translated to: *SELECT FROM [#23:83354, #23:366, #23:99933, #23:80708, #23:70291]* That is MUCH faster. Don't put indexes on RIDs: RIDs are physical positions and are the reason why OrientDB is so fast on traversing and direct loading by RID. Then, in this query you're thinking relational: SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out IN #27:819) Try this (it should take few ms): *SELECT expand(in()) FROM #27:819* If you want to filter by vertex's properties you can do: *SELECT FROM (* * SELECT expand(in()) FROM #27:819) WHERE age = 18* Lvc@ On 3 March 2015 at 11:42, Jamie Blair jamie.bl...@gmail.com wrote: Luigi, Thanks, but there is an extra part to our problem as soon as we want to put conditions on the Vertex we can't. So for our use case we have a lucene index on the Vertex:name, I've found the expand to not be very useful because it kind of backs me into a corner with adding conditions to my query. Is there a list of the current issues with the query optimizer anywhere? Also if anybody could give me an example of how I would also add a lucene condition to the above query that'd be greatly appreciated Thanks, Jamie On Tuesday, March 3, 2015 at 7:21:34 AM UTC, Luigi Dell'Aquila wrote: Hi Jamie, yes, the right thing to make it faster is this: select expand(inV()) FROM SomeEdge WHERE out IN #27:819 Currently there are no work arounds for that at parser level. The problem is not tracked as a single issue because it's a wide topic, and it's being addressed as a full development process, but if you want you can create a specific issue for this Regards Luigi 2015-03-02 18:11 GMT+01:00 Jamie Blair jamie...@gmail.com: Luigi, Have you any idea how I would make this fast, or is there a work around for the present query optimizer? Also is there a ticket I can track in github for this? Thanks, Jamie On Monday, March 2, 2015 at 4:55:51 PM UTC, Luigi Dell'Aquila wrote: Hi Jamie, this is a known issue, we are working hard on the new query parser and executor and one of the main goals of all this is query optimization. Thanks Luigi 2015-03-02 17:11 GMT+01:00 Jamie Blair jamie...@gmail.com: The following query returns a set of `@rid` and completes in about ` 0.012sec` SELECT in FROM SomeEdge WHERE out IN #27:819 Now if I were to select from another Vertex using those `@rid`s in there literal form, this would take a very long time and I get a timeout (above 4seconds). I'm presuming its scanning over all the entries SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, #23:80708, #23:70291] Interestingly enough if I were to use a single `@rid` rather than a set it would be fast. So I'm assuming the query optimizer has the scope to go a little further and also optimize multiple results SELECT FROM SomeVertex WHERE @rid in [#23:83354] But not to worry because I can make this faster by adding an index to `SomeVertex.@rid` so now this is fast again CREATE INDEX foo on SomeVertex (@rid) unique SELECT FROM SomeVertex WHERE @rid in [#23:83354,#23:366,#23:99933,# 23:80708,#23:70291] But if I compose the 2 queries, I'd expect this to be fast, but it's still slow and causes timeout (above 4 seconds) SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out IN #27:819) I'm assuming I could write this in another way, but I'm more interested in why this is slow. Is this a bug or if not are there any details on how/why this is slow? -- --- 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-databa...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are
Re: [orientdb] Distributed OrientDB via Multi-host Docker
Awesome! I'm happy to see so many options now. Back when I had this
problem, couldn't find much of a solution. Glad that users will now have
multiple options where to start from when using ODB with Docker.
@Tobie thank you for your image. Haven't tried yet, but looks solid.
On Thu, Mar 5, 2015 at 7:42 PM, Simon Gemmell simongemm...@gmail.com
wrote:
Here is my set up: orientdb running in a docker container on an AWS server
in Frankfurt, and a similar container on AWS in Sydney. IPSEC tunneling
between them. My docker file looks like this:
FROM dockerfile/java:oracle-java8
MAINTAINER Simon Gemmell
# Update the default application repository sources list
RUN apt-get update
# Install supervisord
RUN apt-get -y install supervisor
RUN mkdir -p /var/log/supervisor
# Install orientdb
ENV ORIENT_VERSION orientdb-community-2.0.3
ENV ORIENT_TAR ${ORIENT_VERSION}.tar.gz
ENV ORIENT_URL
http://www.orientechnologies.com/download.php?file=${ORIENT_TAR}
ENV ROOT /opt
RUN cd ${ROOT} \
curl -o ${ORIENT_TAR} ${ORIENT_URL} \
tar -xzf ${ORIENT_TAR} \
ln -s ${ROOT}/${ORIENT_VERSION} ${ROOT}/orientdb \
ln -s ${ROOT}/orientdb/bin/*.sh /usr/local/bin/ \
mkdir /usr/local/log
# cleanup
RUN apt-get -y -qq --force-yes clean \
rm -rf /opt/downloads/linux /var/lib/apt/lists/* /tmp/* /var/tmp/*
# use supervisord to start orientdb
ADD supervisord.conf /etc/supervisor/conf.d/supervisord.conf
#EXPOSE 2424
EXPOSE 2480
EXPOSE 5701
# Set the user to run OrientDB daemon
USER root
# Default command when starting the container
CMD [/usr/bin/supervisord, -c,
/etc/supervisor/conf.d/supervisord.conf]
I don't expose 2424 as it is linked to another container.
Then I run it like this:
#!/bin/bash
sudo docker run --name orientdb -d -v
`pwd`/orientdb/config:/opt/orientdb/config -v
/mnt/EBS/databases:/opt/orientdb/databases -v
/mnt/EBS/backup:/opt/orientdb/backup -v `pwd`/orientdb/log:/var/log -p
2424:2424 -p 2480:2480 -p 5701:5701 tkbt/orientdb
cd orientdb
./updateip.sh
cd ..
updateip.sh does this:
#!/bin/bash
IP=`sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}'
orientdb`
sed -i 's/property name=hazelcast.local.localAddress.*/property
name=hazelcast.local.localAddress'$IP'\/property/' config/hazelcast.xml
My supervisord:
[supervisord]
nodaemon=true
[program:orientdb]
directory=/opt/orientdb/bin/
command=server.sh -Ddistributed=true -Xmx1024m
autostart=true
autorestart=true
stderr_logfile=/var/log/orientdb.err.log
stdout_logfile=/var/log/orientdb.out.log
; startsecs 5 delays starting orient by 5 secs, which will allow any
external scripts to update IPs etc
startsecs = 5
stopwaitsecs = 120
; make sure we send the signals to any process started by the top scripts
stopasgroup=true
My hazelcastconfig:
properties
property name=hazelcast.mancenter.enabledfalse/property
property name=hazelcast.memcache.enabledfalse/property
property name=hazelcast.rest.enabledfalse/property
property name=hazelcast.wait.seconds.before.join0/property
property name=hazelcast.logging.typejdk/property
property
name=hazelcast.local.localAddress172.17.0.22/property
property
name=hazelcast.socket.server.bind.anyfalse/property
property name=hazelcast.socket.client.bindfalse/property
/properties
network
!-- CHANGE: This is the public ip address of the host: --
public-address10.0.1.96/public-address
!-- CHANGE: This port should be mapped on the docker level,
e.g. -p 5701:5701: --
port auto-increment=false port-count=1005701/port
outbound-ports
!--
Allowed port range when connecting to other nodes.
0 or * means use system provided port.
--
ports0/ports
/outbound-ports
join
!-- CHANGE: disable multicast --
multicast enabled=false
multicast-group224.2.2.3/multicast-group
multicast-port54327/multicast-port
/multicast
!-- CHANGE: enable tcp-ip and specify the public ip
addresses of all the hosts that should communicate --
tcp-ip enabled=true
interface172.31.6.12/interface
/tcp-ip
/join
/network
executor-service
pool-size16/pool-size
/executor-service
...
On Thursday, March 5, 2015 at 6:32:36 AM UTC+11, Tobie Morgan Hitchcock
wrote:
Hi Luca,
Docker differences
1. Using `centos:7` not `debian`
2. Using `java-1.7.0-openjdk-headless` instead of `java-1.7.0-openjdk`
3. The OrientDB install tar file (https://abcum-deploy.s3.
amazonaws.com/orient/orientdb-community-2.0.4.tar.gz) is an exact copy
of the one available at
[orientdb] Analytics data
Relative newbie Currently testing/building Analytical app with OrientDB. Really like it al lot! One thing that i cant figure out is the best way to import (historical) google analytics data on a daily base. Is the use of indexes the way to go? Or do i create Vertex for every adwords campaign per day and add an edge with date property from campaginID? Order - E - AdcampaingId - E (date) - campaingdata of day X Would create massive amount of documents... does that impact performance? Cant find other users/documentation besides couple of links that point to indexes. A point in the right direction would help me a lot! Thx Regards, Coen -- --- 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.
[orientdb] Re: Adding edges with properties after using Document API
Actually the better approach for me is to stick with the document api and do like so: ODatabaseDocumentTx db = pool.acquire(); OrientGraph g = new OrientGraph(db); Out of interest is the a way to cast ODocument to Vertex and vice versa? PS Would be nice if you could provide a one liner in the wiki for the Document API and for the Graph API how to get the otherone. This my help new commers a lot. -- --- 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.
[orientdb] Re: Record deadlock issue in 2.0.2
I am getting this error too. Any progress on this issue? My application is running OrientDB 2.0.4 Jing -- --- 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.
[orientdb] Re: How to get records that are linked to each of given vertices
Ok here is an example:
CREATE DATABASE remote:localhost/testdb root root memory
CREATE CLASS Data EXTENDS V;
CREATE PROPERTY Data.id INTEGER;
CREATE CLASS Tag EXTENDS V;
CREATE PROPERTY Tag.name STRING;
CREATE CLASS hasTag EXTENDS E;
CREATE VERTEX Data SET id = 1;
CREATE VERTEX Data SET id = 2;
CREATE VERTEX Tag SET name = 'A';
CREATE VERTEX Tag SET name = 'B';
#Link to both A and B
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 1) TO (SELECT FROM Tag
WHERE name = 'A');
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 1) TO (SELECT FROM Tag
WHERE name = 'B');
#Link only to A
CREATE EDGE hasTag FROM (SELECT FROM Data WHERE id = 2) TO (SELECT FROM Tag
WHERE name = 'A');
#Get Data that is linked to both (Tag vertices having name) A and B, should
get Data with id = 1
SELECT FROM Data WHERE out('hasTag') CONTAINS (name = 'A') AND out('hasTag')
CONTAINS (name = 'B');
In my app Tag vertices (having name 'A' and 'B') are provided by the client
app and could be more than 2 Tags, that's why I'm trying to avoid the *CONTAINS
... AND CONTAINS* ... part, when building my query.
Thank you for your patience.
On Friday, 6 March 2015 05:36:04 UTC+1, Colin wrote:
If A, B, C are all vertices and each represents a different type of class,
then you could could create a different edge type for each one.
Are A, B, C all unique types that derive from a common base?
Maybe if you can give a more real-world example with the needed result, we
can figure it out.
Sorry, if I'm being dense. :-)
-Colin
On Thursday, March 5, 2015 at 4:05:44 PM UTC-6, Red-0ne wrote:
Sorry for being misleading. A, B, C are vertices of themselves and
created through CREATE VERTEX command. I just tried to represent them by
their @rids in the above query.
On Thursday, 5 March 2015 16:51:14 UTC+1, Colin wrote:
I think I'm a little puzzled why/how A, B are @rids and vertices but
not. :-)
Are A, B, C always unique 'tags' as in properties of vertices that
denote some kind of type? Or, are A, B, C types of vertices themselves?
On Thursday, March 5, 2015 at 5:37:37 AM UTC-6, Red-0ne wrote:
Actually vertices A, B, C... are kind of *tags*, and Vi are *data*. My
use case is as simple as: get data that matches *all* given tags.
On Tuesday, 3 March 2015 19:19:58 UTC+1, Colin wrote:
--
---
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.
[orientdb] Custom Serialization of Embedded Documents
Hi everyone,
while playing around with OrientDB 2.0.4 I encountered the following
problem:
I have the following (schematic) classes
public class ClassA{
private String someData;
private ClassB embeddedClass;
}
public class ClassB implements Serializable{
private Integer someData;
private ClassC classToBeReferenced;
}
public class ClassC implements Serializable{
private Boolean someData;
}
Allthough ClassC should not be embedded but referenced in ClassB, ClassB
contains an actual instance of ClassC so that people can easily set an
instance of ClassC on ClassB (and not have to deal with OrientDB to get the
RID of the instance of ClassC).
The problem with this setup is that OrientDB embeds ClassC in ClassB when
an instance of ClassB is serialized. In order to avoid that I created a
custom serializer for ClassC:
public class ClassCSerializer implements OObjectSerializerClassC, ORID {
}
My problem is now, that the solution with the custom implementation of
OObjectSerializer does not seem to work in verison 2.0.4 anymore, since I
cannot find an OObjectSerializerContext where the serializers can be added
to. I have orient-core, -client and -enterprise modules in version 2.0.4 on
my classpath.
Futhermore, I've tried to solve the problem by implementing
ODocumentSerializable with ClassB. But this is not an ideal solution
either, since the ODocument, which is created by the toDocument() method is
stored as an own entry in the database.
Can anybody help me out here?
Regards, Pascal
--
---
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.
Re: [orientdb] compound index seems to be ignored
Hi, A small sample database and the query you execute will be enough Thanks Luigi 2015-03-05 21:18 GMT+01:00 Máté Gábri gabrim...@gmail.com: Hi Luigi, sorry I'm new to this so please forgive my noob question. What should I provide so that you can test it? My code (nodejs) I'm using for testing, or some test data with the query and index I'm using? Best regards, Mate On Thursday, March 5, 2015 at 10:51:26 AM UTC+1, Luigi Dell'Aquila wrote: Hi Mate, there are no limitations in the number of properties that can be indexed, so there must be a bug somewhere. Could you provide a test case to reproduce it? Thanks Luigi 2015-03-04 22:25 GMT+01:00 Máté Gábri gabr...@gmail.com: Hi, I'm trying to get familiar with OrientDB's indexing to make some performance tests. I'm running a query on a class which uses 10+ conditions in the WHERE statement with range selections, constants and IN conditions. I've created the compound index in the same order as the fields appear in the WHERE statement but it seems like the index is ignored. The EXPLAIN command shows that the index is used, but the scanned documents number is the same as the number of documents in the class. After some experimentation I came to the conclusion that with 2 conditions the index is working, so just part of the class is scanned, but after adding the third condition the whole class is scanned. I'm just not sure wether this is normal behaviour or not. Am I missing something? Best regards, Mate -- --- 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-databa...@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. -- --- 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.
