Excellent, glad it’s working!
The spgemm code does indeed execute on every cluster instance. For short duration queries you have a better chance of seeing activity on just the “coordinator” node (the one that the iquery client or the shim is actually connecting to), since the non-distributed work of query execution happens there (parsing the query, broadcasting it to workers, merging their responses, managing locks, etc.) happens there.
Also, chunks of the array(s) are distributed across the cluster based on a hash algorithm, so it’s possible that some instances have more work to do than others. That’s especially true when the arrays are relatively small: for a large number of chunks the hash function does a good job of even distribution, but for small chunk counts the distribution can be bumpy. You can use the undocumented (because subject to change without notice) list(‘chunk maps’) query to get an understanding of how a particular array’s chunks are distributed. This recent thread describes it: “Find out the size of a compressed array”. Chunk size and distribution have a big impact on query performance. Once your proof-of-concept queries are working, it’s time to search this forum for ways to optimize, perhaps by adjusting the chunk sizes of your array dimensions to get a better distribution.
So short answer is, I don’t know why your particular query seems to be exercising just the one node, but there are legitimate reasons why it could be.