For GSQL beginners, they often want to understand what POST-ACCUM v.s. ACCUM.
- ACCUM clause executes its statements in parallel for each match in the FROM clause.
- POST-ACCUM clause executes its statement(s) once for each involved vertex. Note that each statement within the POST-ACCUM clause can refer to either source vertices or target vertices but not both. Its statements can access the aggregated accumulator result computed in the ACCUM clause.
POST-ACCUM clause allows you to access the aggregate result of the ACCUM clause. And it can iterate through all distinct matched vertices belonging to a vertex set accessible by a binding variable (alias) specified in the FROM clause pattern.
Since 3.5 release, we allow multiple POST-ACCUM per query block (a SELECT statement).
For example, below we have three POST-ACCUM clauses.
INTERPRET QUERY () {
SumAccum @cnt1;
SumAccum @cnt2;
R = SELECT s
FROM Person:s-(LIKES>) -:msg - (HAS_CREATOR>)-Person:t
WHERE s.firstName == “Viktor” AND s.lastName == “Akhiezer”
AND t.lastName LIKE “S%” AND year(msg.creationDate) == 2012
ACCUM s.@cnt1 +=1 //execute this per match of the FROM pattern.
POST-ACCUM s.@cnt2 += s.@cnt1 //(1)
POST-ACCUM t.@cnt2 +=1; //(2)
POST-ACCUM (t) @@globalTCount += 1; (3)
PRINT R [R.firstName, R.lastName, R.@cnt1, R.@cnt2];
}
(1) The first one iterates through s, and for each s, we do s.@cnt2 += s.@cnt1. The s represents the vertex set denoted by s that projected from all the matches of the FROM clauses.
(2)The second POST-ACCUM iterates through t.
(3) The third POST-ACCUM also iterates through t, but its DML-sub statements do not reference t. Rather, the POST-ACCUM is bound to t explicitly by “(t)”
However, the following is not allowed, since it involves two aliases (t and s) in one POST-ACCUM clause.
POST-ACCUM t.@cnt1 += 1,
s.@cnt1 += 1
Also, you may not use more than one alias in a single assignment. The following is not allowed:
POST-ACCUM t.@cnt1 += s.@cnt + 1
See more explanation here