I have a following statement and it generates the mentioned output by averaging data within every 20 minutes of range.
Statement :
SELECT record_no, date_time,
ROUND(AVG(UNIX_TIMESTAMP(date_time))) AS time_value,
ROUND(AVG(ph1_active_power),4) AS p1,
ROUND(AVG(ph2_active_power),4) AS p2,
ROUND(AVG(ph3_active_power),4) AS p3
FROM powerpro1
GROUP BY date_time DIV 2000
Portion of the output
+-----------+---------------------+------------+---------+----------+----------+
| record_no | date_time | time_value | p1 | p2 | p3 |
+-----------+---------------------+------------+---------+----------+----------+
| 1 | 2014-12-01 00:00:00 | 1417372770 | 72.6242 | -68.7428 | -72.6242 |
| 21 | 2014-12-01 00:20:00 | 1417373970 | 71.6624 | -69.7448 | -71.6624 |
| 41 | 2014-12-01 00:40:00 | 1417375170 | 70.6869 | -70.7333 | -70.6869 |
| 61 | 2014-12-01 01:00:00 | 1417376370 | 69.6977 | -71.7082 | -69.6977 |
| 81 | 2014-12-01 01:20:00 | 1417377570 | 68.6952 | -72.6692 | -68.6952 |
| 101 | 2014-12-01 01:40:00 | 1417378770 | 67.6794 | -73.6162 | -67.6794 |
| 121 | 2014-12-01 02:00:00 | 1417379970 | 66.6505 | -74.549 | -66.6505 |
| 141 | 2014-12-01 02:20:00 | 1417381200 | 65.5825 | -75.4901 | -65.5825 |
+-----------+---------------------+------------+---------+----------+----------+
According to the no of records in the table named "powerpro1", the above query selects 1368 records when the executing. (May be increased in the future when receiving new records)
My requirement is to create a highchart using time_value for the x-axis and p1, p1 and p3 for the y-axis. But I needs to limit the no of points in the x-axis.
Can anyone like to help me to show this 1368 points by 1000 points in the chart
Unfortunately have no this kind of apporixmation, only in reverse order (I mean datagrouping, if you have 100 points, return i.e 10). So you need to calcualte it on your own and push to your data all 1000 points.
Related
I am trying out neo4j to work on my grade project and I decided to create a database with the datagen provided by LDBC. This datagen came with these queries.
So I decided to run one of those queries and collected it's execution time (I ran them using cypher-shell command). So I collected these times:
553575, 558724, 556443, 556675, 551304, 555385, 552896
Note: I took the first run out because as said in this post the first time seemed to be a spike due to cold-cache.
Everything smooth until here, then I've decided to create some paths with new labels, making the database grow from 1.5GB to 2.4GB. The I decided to run again the queries expecting for them to be slower. For my surprise I saw that the times were substantially smaller.
382331, 380566, 405636, 405953, 407277, 391804, 371134, ....
From this post. I expected them to be like all be around a same time (like the first run) and perhaps bigger, but definitely not smaller.
For the purpose of this question, I am using an AWS machine, especifically the i3.4xlarge instance (16 vCPUs, 122GB RAM and 2x 1.9TB NVMe SSD). The current version I am using of Neo4j is 3.3.5 and I am using cypher-shell as stated above.
Additionally I have no other programs/process running on this machine so I think we can just eliminate that issue (and despite that being the case, it should slow them down, not speed them up).
Thanks in advance, I am just asking to see if someone may shed some light for me on this issue :)
EDIT:
The changes I've made were added some paths between :Message nodes and :Person's. Also some between :Person and :Person, some between :TagClass (other label) and :Person. Additionally, the DB had index on :Tag(name), :Person(name), :TagClass(name) and :Country(name) but for the purpose of executing the query, dropped those.
The original query:
PROFILE
MATCH (tag:Tag {name: 'Arnold_Schwarzenegger'})
MATCH (tag)<-[:HAS_TAG]-(message1:Message)-[:HAS_CREATOR]->(person1:Person)
MATCH (tag)<-[:HAS_TAG]-(message2:Message)-[:HAS_CREATOR]->(person1)
OPTIONAL MATCH (message2)<-[:LIKES]-(person2:Person)
OPTIONAL MATCH (person2)<-[:HAS_CREATOR]-(message3:Message)<-[like:LIKES]-(p3:Person)
RETURN
person1.id,
count(DISTINCT like) AS authorityScore
ORDER BY
authorityScore DESC,
person1.id ASC
LIMIT 100
These are profiles from both runs, due to space only added one plan. I can assure you, they're both the exact same (even on db hits, paths expanded, everything):
1st run:
| Plan | Statement | Version | Planner | Runtime | Time | DbHits | Rows |
| "PROFILE" | "READ_ONLY" | "CYPHER 3.3" | "COST" | "INTERPRETED" | 556443 | 0 | 100 |
2nd:
| Plan | Statement | Version | Planner | Runtime | Time | DbHits | Rows |
| "PROFILE" | "READ_ONLY" | "CYPHER 3.3" | "COST" | "INTERPRETED" | 371134 | 0 | 100 |
Plan:
+----------------------+----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| Operator | Estimated Rows | Rows | DB Hits | Cache H/M | Identifiers | Other |
+----------------------+----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +ProduceResults | 100 | 100 | 0 | 0/0 | anon[349], anon[355], authorityScore, person1.id | 0.0 |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Projection | 100 | 100 | 0 | 0/0 | anon[349], anon[355], authorityScore, person1.id | 0.0; {person1.id : , authorityScore : } |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Top | 100 | 100 | 0 | 0/0 | anon[349], anon[355] | 0.0; 100; anon[355], anon[349] |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +EagerAggregation | 126593 | 1842 | 49948155 | 0/0 | anon[349], anon[355] | 0.0; anon[349] |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Apply | 16025884097 | 49948155 | 0 | 0/0 | person2, anon[219], message3, anon[60], tag, anon[136], p3, message1, anon[167], anon[271], message2, anon[91], person1, like | 0.0 |
| |\ +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Optional | 7317 | 49948155 | 0 | 0/0 | person2, message3, p3, anon[271], like | 0.0 |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Filter | 5037 | 49897917 | 49897917 | 0/0 | person2, message3, p3, anon[271], like | 0.0; p3:Person |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Expand(All) | 5037 | 49897917 | 108680609 | 0/0 | person2, message3, p3, anon[271], like | 0.0; (message3)<-[like:LIKES]-(p3) |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Filter | 7028 | 58782692 | 58782692 | 0/0 | anon[271], message3, person2 | 0.0; message3:Message |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Expand(All) | 7028 | 58782692 | 58866898 | 0/0 | anon[271], message3, person2 | 0.0; (person2)<-[anon[271]:HAS_CREATOR]-(message3) |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Argument | 7317 | 130898 | 0 | 0/0 | person2 | 0.0 |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +OptionalExpand(All) | 7317 | 130898 | 220191 | 0/0 | person2, anon[219], anon[60], tag, anon[136], message1, anon[167], message2, anon[91], person1 | 0.0; (message2)<-[anon[219]:LIKES]-(person2); person2:Person |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +NodeHashJoin | 7317 | 51779 | 0 | 0/0 | anon[60], tag, anon[136], message1, anon[167], message2, anon[91], person1 | 0.0; tag, person1 |
| |\ +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Filter | 341165 | 4241 | 4241 | 0/0 | tag, anon[136], anon[167], message2, person1 | 0.0; person1:Person |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Expand(All) | 341165 | 4241 | 8482 | 0/0 | tag, anon[136], anon[167], message2, person1 | 0.0; (message2)-[anon[167]:HAS_CREATOR]->(person1) |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Filter | 341165 | 4241 | 4646 | 0/0 | anon[136], message2, tag | 0.0; message2:Message |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Expand(All) | 372142 | 4646 | 4647 | 0/0 | anon[136], message2, tag | 0.0; (tag)<-[anon[136]:HAS_TAG]-(message2) |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +Filter | 1608 | 1 | 16080 | 0/0 | tag | 0.0; tag.name = { AUTOSTRING0} |
| | | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| | +NodeByLabelScan | 16080 | 16080 | 16081 | 0/0 | tag | 0.0; :Tag |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Filter | 341165 | 4241 | 4241 | 0/0 | anon[60], tag, message1, anon[91], person1 | 0.0; person1:Person |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Expand(All) | 341165 | 4241 | 8482 | 0/0 | anon[60], tag, message1, anon[91], person1 | 0.0; (message1)-[anon[91]:HAS_CREATOR]->(person1) |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Filter | 341165 | 4241 | 4646 | 0/0 | anon[60], message1, tag | 0.0; message1:Message |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Expand(All) | 372142 | 4646 | 4647 | 0/0 | anon[60], message1, tag | 0.0; (tag)<-[anon[60]:HAS_TAG]-(message1) |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +Filter | 1608 | 1 | 16080 | 0/0 | tag | 0.0; tag.name = { AUTOSTRING0} |
| | +----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
| +NodeByLabelScan | 16080 | 16080 | 16081 | 0/0 | tag | 0.0; :Tag |
+----------------------+----------------+----------+-----------+-----------+-------------------------------------------------------------------------------------------------------------------------------+------------------------------ --------------------------------+
... Results ...
100 rows available after 371134 ms, consumed after another 0 ms
Note: SO Doesn't allow me to write over 30000 characters so had to reduce the text.
The Cypher planner takes the current characteristics of the DB into account when deciding how to carry out a query. Any changes to a DB can alter the execution plan, which can greatly affect the timing.
The best way to understand timing differences after updating a DB is to do before-and-after comparisons of the query profile. Without knowing what query you are using, and especially without the before-and-after profile information (neither of which were provided), it is difficult to impossible to figure out why the timing changed.
The only guess that can be made, with the little information available, is that the timing had changed because the DB characteristics had changed in ways that caused the planner to alter the execution plan.
My problem on getting one row shown with two null values.
FROM tuotemerkki;
tmtunnus | tmnimi | maa
----------+----------+-------------
1 | McCee | Yhdysvallat
2 | KooTek | Italia
3 | Giardino | Italia
(3 rows)
FROM tuote;
ttunnus | tnimi | kuvaus | suositushinta | tmtunnus
---------+-----------------------+--------------------+---------------+----------
111 | Trimmeri TRCee | tehokas 4-tahtinen | 179.00 | 1
112 | Trimmerisiima Cee | laadukas siima | 6.99 | 1
113 | Moottorisaha MSCee RR | robusti ja raskas | 559.00 | 1
114 | Trimmerisiima Y | yleissiima | 3.99 | 2
115 | Lapio L | kevyt yleislapio | 23.95 | 2
(5 rows)
I need to get this selected with the NULL VALUE on giardino from tmnimi.
tmnimi | tnimi | kuvaus
----------+-----------------------+--------------------
McCee | Trimmeri TRCee | tehokas 4-tahtinen
McCee | Trimmerisiima Cee | laadukas siima
McCee | Moottorisaha MSCee RR | robusti ja raskas
KooTek | Trimmerisiima Y | yleissiima
KooTek | Lapio L | kevyt yleislapio
Giardino | |
(6 rows)
I get only this selected
SELECT tmnimi, tnimi, kuvaus
FROM tuote
CROSS JOIN tuotemerkki
WHERE tuote.tmtunnus = tuotemerkki.tmtunnus;
tmnimi | tnimi | kuvaus
--------+-----------------------+--------------------
McCee | Trimmeri TRCee | tehokas 4-tahtinen
McCee | Trimmerisiima Cee | laadukas siima
McCee | Moottorisaha MSCee RR | robusti ja raskas
KooTek | Trimmerisiima Y | yleissiima
KooTek | Lapio L | kevyt yleislapio
(5 rows)
Use a left join between the two tables:
SELECT
t1.tmnimi,
t2.tnimi,
t2.kuvaus
FROM tuotemerkki t1
LEFT JOIN tuote t2
ON t1.tmtunnus = t2.tmtunnus
When you left join from tuotemerkki to tuote, then every record in the former table is guaranteed to appear in the result set. Since the Giardino record does not match to anything in the tuote table, all the columns from that table would have a NULL value for the Giardino record.
I have a tree structure like node(1)->node(2)->node(3). I have name as an property used to retrieve a node.
Given a node say node(3), i wanna retrieve node(1).
Query tried :
MATCH (p:Node)-[:HAS*]->(c:Node) WHERE c.name = "node 3" RETURN p LIMIT 5
But, not able to get node 1.
Your query will not only return "node 1", but it should at least include one path containing it. It's possible to filter the paths to only get the one traversing all the way to the root, however:
MATCH (c:Node {name: "node 3"})<-[:HAS*0..]-(p:Node)
// The root does not have any incoming relationship
WHERE NOT (p)<-[:HAS]-()
RETURN p
Note the use of the 0 length, which matches all cases, including the one where the start node is the root.
Fun fact: even if you have an index on Node:name, it won't be used (unless you're using Neo4j 3.1, where it seems to be fixed since 3.1 Beta2 at least) and you have to explicitly specify it.
MATCH (c:Node {name: "node 3"})<-[:HAS*0..]-(p:Node)
USING INDEX c:Node(name)
WHERE NOT (p)<-[:HAS]-()
RETURN p
Using PROFILE on the first query (with a numerical id property instead of name):
+-----------------------+----------------+------+---------+-------------------------+----------------------+
| Operator | Estimated Rows | Rows | DB Hits | Variables | Other |
+-----------------------+----------------+------+---------+-------------------------+----------------------+
| +ProduceResults | 0 | 1 | 0 | p | p |
| | +----------------+------+---------+-------------------------+----------------------+
| +AntiSemiApply | 0 | 1 | 0 | anon[23], c -- p | |
| |\ +----------------+------+---------+-------------------------+----------------------+
| | +Expand(All) | 1 | 0 | 3 | anon[58], anon[67] -- p | (p)<-[:HAS]-() |
| | | +----------------+------+---------+-------------------------+----------------------+
| | +Argument | 1 | 3 | 0 | p | |
| | +----------------+------+---------+-------------------------+----------------------+
| +Filter | 1 | 3 | 3 | anon[23], c, p | p:Node |
| | +----------------+------+---------+-------------------------+----------------------+
| +VarLengthExpand(All) | 1 | 3 | 5 | anon[23], p -- c | (c)<-[:HAS*]-(p) |
| | +----------------+------+---------+-------------------------+----------------------+
| +Filter | 1 | 1 | 3 | c | c.id == { AUTOINT0} |
| | +----------------+------+---------+-------------------------+----------------------+
| +NodeByLabelScan | 3 | 3 | 4 | c | :Node |
+-----------------------+----------------+------+---------+-------------------------+----------------------+
Total database accesses: 18
and on the second one:
+-----------------------+----------------+------+---------+-------------------------+------------------+
| Operator | Estimated Rows | Rows | DB Hits | Variables | Other |
+-----------------------+----------------+------+---------+-------------------------+------------------+
| +ProduceResults | 0 | 1 | 0 | p | p |
| | +----------------+------+---------+-------------------------+------------------+
| +AntiSemiApply | 0 | 1 | 0 | anon[23], c -- p | |
| |\ +----------------+------+---------+-------------------------+------------------+
| | +Expand(All) | 1 | 0 | 3 | anon[81], anon[90] -- p | (p)<-[:HAS]-() |
| | | +----------------+------+---------+-------------------------+------------------+
| | +Argument | 1 | 3 | 0 | p | |
| | +----------------+------+---------+-------------------------+------------------+
| +Filter | 1 | 3 | 3 | anon[23], c, p | p:Node |
| | +----------------+------+---------+-------------------------+------------------+
| +VarLengthExpand(All) | 1 | 3 | 5 | anon[23], p -- c | (c)<-[:HAS*]-(p) |
| | +----------------+------+---------+-------------------------+------------------+
| +NodeUniqueIndexSeek | 1 | 1 | 2 | c | :Node(id) |
+-----------------------+----------------+------+---------+-------------------------+------------------+
Total database accesses: 13
I have following simple relationship between (:User) nodes.
(:User)-[:FOLLOWS {timestamp}]->(:User)
If I paginate followers ordered by FOLLOWS.timestamp I'm running into performance problems when someone has millions of followers.
MATCH (u:User {Id:{id}})<-[f:FOLLOWS]-(follower)
WHERE f.timestamp <= {timestamp}
RETURN follower
ORDER BY f.timestamp DESC
LIMIT 100
What is suggested approach for paginating big sets of data when ordering is required?
UPDATE
follower timestamp
---------------------------------------
id(1000000) 1455967905
id(999999) 1455967875
id(999998) 1455967234
id(999997) 1455967123
id(999996) 1455965321
id(999995) 1455964123
id(999994) 1455963645
id(999993) 1455963512
id(999992) 1455961343
....
id(2) 1455909382
id(1) 1455908432
I want to slice this list down using timestamp which set on :FOLLOWS relationship. If I want to return batches of 4 followers I take current timestamp first and return 4 most recent, then 1455967123 and 4 most recent and so on. In order to do this the whole list should be order by timestamp which results in performance issues on millions of records.
If you're looking for the most recent followers, i.e. where the timestamp is greater than a given time, it only has to traverse the most recent ones.
You can do it with (2) in 20ms
If you are really looking for the oldest (first) followers it makes sense to skip ahead and don't look at the timestamp of every of the million followers (which takes about 1s on my system, see (3)). If you skip ahead the time goes down to 230ms, see (1)
In general we can see that on my laptop it does 2M db-operations per core and second.
(1) Look at first / oldest followers
PROFILE
> MATCH (u)<-[f:FOLLOWS]-(follower) WHERE id(u) = 0
> // skip ahead
> WITH f,follower SKIP 999000
> // do the actual check
> WITH f,follower WHERE f.ts < 500
> RETURN f, follower
> ORDER BY f.ts
> LIMIT 10;
+---------------------------------+
| f | follower |
+---------------------------------+
| :FOLLOWS[0]{ts:1} | Node[1]{} |
...
+---------------------------------+
10 rows
243 ms
Compiler CYPHER 2.3 Planner COST Runtime INTERPRETED
+-----------------+----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| Operator | Estimated Rows | Rows | DB Hits | Identifiers | Other |
+-----------------+----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +ProduceResults | 1 | 10 | 0 | f, follower | f, follower |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Projection | 1 | 10 | 0 | anon[142], anon[155], anon[158], anon[178], f, follower, f, follower, u | anon[155]; anon[158] |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Top | 1 | 10 | 0 | anon[142], anon[155], anon[158], anon[178], f, follower, u | Literal(10); |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Projection | 1 | 499 | 499 | anon[142], anon[155], anon[158], anon[178], f, follower, u | anon[155]; anon[158]; anon[155].ts |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Projection | 1 | 499 | 0 | anon[142], anon[155], anon[158], f, follower, u | f; follower |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Filter | 1 | 499 | 0 | anon[142], f, follower, u | anon[142] |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Projection | 1 | 1000 | 1000 | anon[142], f, follower, u | f; follower; f.ts < { AUTOINT2} |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Skip | 1 | 1000 | 0 | f, follower, u | { AUTOINT1} |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +Expand(All) | 1 | 1000000 | 1000001 | f, follower, u | (u)<-[ f#12:FOLLOWS]-( follower#24) |
| | +----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
| +NodeByIdSeek | 1 | 1 | 1 | u | |
+-----------------+----------------+---------+---------+-------------------------------------------------------------------------+---------------------------------------+
Total database accesses: 1001501
(2) Look at most recent followers
PROFILE
> MATCH (u)<-[f:FOLLOWS]-(follower) WHERE id(u) = 0
> AND f.ts > 999500
> RETURN f, follower
> LIMIT 10;
+----------------------------------------------+
| f | follower |
+----------------------------------------------+
| :FOLLOWS[999839]{ts:999840} | Node[999840]{} |
...
+----------------------------------------------+
10 rows
23 ms
Compiler CYPHER 2.3 Planner COST Runtime INTERPRETED
+-----------------+----------------+-------+---------+----------------+---------------------------------------------------------------+
| Operator | Estimated Rows | Rows | DB Hits | Identifiers | Other |
+-----------------+----------------+-------+---------+----------------+---------------------------------------------------------------+
| +ProduceResults | 1 | 10 | 0 | f, follower | f, follower |
| | +----------------+-------+---------+----------------+---------------------------------------------------------------+
| +Limit | 1 | 10 | 0 | f, follower, u | Literal(10) |
| | +----------------+-------+---------+----------------+---------------------------------------------------------------+
| +Filter | 1 | 10 | 16394 | f, follower, u | AndedPropertyComparablePredicates(f,f.ts,f.ts > { AUTOINT1}) |
| | +----------------+-------+---------+----------------+---------------------------------------------------------------+
| +Expand(All) | 1 | 16394 | 16395 | f, follower, u | (u)<-[f:FOLLOWS]-(follower) |
| | +----------------+-------+---------+----------------+---------------------------------------------------------------+
| +NodeByIdSeek | 1 | 1 | 1 | u | |
+-----------------+----------------+-------+---------+----------------+---------------------------------------------------------------+
Total database accesses: 32790
(3) Find oldest followers without skipping ahead
PROFILE
> MATCH (u)<-[f:FOLLOWS]-(follower) WHERE id(u) = 0
> AND f.ts < 500
> RETURN f, follower
> LIMIT 10;
+-------------------------------------+
| f | follower |
+-------------------------------------+
...
| :FOLLOWS[491]{ts:492} | Node[492]{} |
+-------------------------------------+
10 rows
1008 ms
Compiler CYPHER 2.3 Planner COST Runtime INTERPRETED
+-----------------+----------------+--------+---------+----------------+---------------------------------------------------------------+
| Operator | Estimated Rows | Rows | DB Hits | Identifiers | Other |
+-----------------+----------------+--------+---------+----------------+---------------------------------------------------------------+
| +ProduceResults | 1 | 10 | 0 | f, follower | f, follower |
| | +----------------+--------+---------+----------------+---------------------------------------------------------------+
| +Limit | 1 | 10 | 0 | f, follower, u | Literal(10) |
| | +----------------+--------+---------+----------------+---------------------------------------------------------------+
| +Filter | 1 | 10 | 999498 | f, follower, u | AndedPropertyComparablePredicates(f,f.ts,f.ts < { AUTOINT1}) |
| | +----------------+--------+---------+----------------+---------------------------------------------------------------+
| +Expand(All) | 1 | 999498 | 999499 | f, follower, u | (u)<-[f:FOLLOWS]-(follower) |
| | +----------------+--------+---------+----------------+---------------------------------------------------------------+
| +NodeByIdSeek | 1 | 1 | 1 | u | |
+-----------------+----------------+--------+---------+----------------+---------------------------------------------------------------+
Total database accesses: 1998998
Is it possible to do union of two queries (from the same entity) in core data? In SQL speak, if entity is called t, then consider that T has following data:
+------+------+------+
| x | y | z |
+------+------+------+
| 1 | 11 | 2 |
| 1 | 12 | 3 |
| 2 | 11 | 1 |
| 3 | 12 | 3 |
Then I am trying to run the following query (using core data - not SQLite)
select x, y, sum(z)
from t
group by 1, 2
union
select x, 1 as y, sum(z)
from t
group by 1, 2
order by x, y, 1
;
+------+------+--------+
| x | y | sum(z) |
+------+------+--------+
| 1 | 1 | 5 |
| 1 | 11 | 2 |
| 1 | 12 | 3 |
| 2 | 1 | 1 |
| 2 | 11 | 1 |
| 3 | 1 | 3 |
| 3 | 12 | 3 |
+------+------+--------+
7 rows in set (0.00 sec)
Is it possible?
Thanks!