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
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
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
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
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
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
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.bl...@gmail.com:
The following query returns a set of `@rid` and completes in
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
