Triangle Count All
SQL function: cugraph_triangle_count_all
Official cuGraph reference: C API
Count the number of three-vertex cycles incident to every vertex in the graph.
Quickstart
The call below supplies edges from registered relation target_edges with canonical src and dst columns and may include weight. Substitute your own registered relations.
SELECT * FROM cugraph_triangle_count_all(edges => (SELECT src, dst FROM target_edges));
Inputs
Every relation is a named parenthesized SELECT subquery. The required edges role uses canonical src and dst columns; every role, its canonical columns, and their accepted Arrow types are listed under Relation arguments. Metadata validation resolves registered tables named in its JSON request.
Endpoint columns accept numeric Int32, Int64 vertex IDs or logical string Utf8, LargeUtf8, Utf8View vertex IDs; string vertex-identity outputs are canonicalized to Utf8 (native mapping Int64) while scores, distances, counts, coordinates, and opaque labels stay numeric. The shared vertex-ID contract is summarized in Vertex ID support; the concrete call-specific schema comes from gpu_validate_call.
Logical string side-input limitations:
- edge ID columns and edge-ID predicate side inputs are not supported for logical string graphs
Arguments and options
Relation arguments
| Argument | Required | Columns | Description |
|---|---|---|---|
edges | yes |
| edge relation with canonical src and dst columns, plus optional weight and edge_id columns |
Every edge_id column must have the integer type of src and dst; string-keyed graphs accept no edge IDs.
Named value arguments
This function has no algorithm-specific value arguments. Its inputs are the relation arguments above and the graph construction options below.
Graph construction options
This function requires directed=false (undirected/symmetric graph); all other graph construction options follow the shared defaults documented in Graph Construction Options.
Output
| Column | Type | Nullable | Description |
|---|---|---|---|
vertex | Int64|Utf8 | no | Vertex whose triangle participation is reported. |
triangle_count | Int64 | no | Number of triangles incident to the vertex. |
These are generic descriptor schemas; run gpu_validate_call to get the concrete, table-specific output schema.
Examples
These examples run on the citation network demo dataset.
Count every triangle in 45.6M edges
A triangle in a citation graph is a paper that cites two works which also cite each other, forming the unit of tightly interlinked literature. One call counts them for every vertex (edges are treated as undirected):
SELECT COUNT(*) AS vertices,
SUM(triangle_count) AS triangle_sum,
MAX(triangle_count) AS max_triangles
FROM cugraph_triangle_count_all(edges => (SELECT src, dst FROM citation_edges));
| vertices | triangle_sum | max_triangles |
|---|---|---|
| 4,146,772 | 202,557,720 | 143,168 |
SUM counts each triangle once per corner, so the graph holds ~67.5M distinct
triangles; the busiest single paper (the SIFT paper, Distinctive Image
Features from Scale-Invariant Keypoints) sits on 143,168 of them. In this run
the full scan, GPU graph build, and count returned in about 0.6 s on the
capture host.
Local clustering coefficient in plain SQL
Raw triangle counts track degree. Normalizing by the possible neighbor pairs
(the local clustering coefficient 2T / (d·(d−1))) separates communities
from hubs. With {"directed": false} the in_degree column of
cugraph_degrees_all is exactly the triangle graph's neighbor count, so two
GPU calls joined in SQL give the coefficient:
WITH tri AS (
SELECT vertex, triangle_count
FROM cugraph_triangle_count_all(edges => (SELECT src, dst FROM citation_edges))),
deg AS (
SELECT vertex, in_degree AS degree
FROM cugraph_degrees_all(
edges => (SELECT src, dst FROM citation_edges), directed => false))
SELECT p.title, p.year, d.degree, t.triangle_count,
ROUND(2.0 * t.triangle_count / (d.degree * (d.degree - 1)), 3) AS clustering
FROM tri t
JOIN deg d ON d.vertex = t.vertex
JOIN papers p ON p.paper_id = t.vertex
WHERE d.degree >= 200
ORDER BY clustering DESC
LIMIT 5;
| title | year | degree | triangle_count | clustering |
|---|---|---|---|---|
| Out of Control: Overcoming Control-Flow Integrity | 2014 | 208 | 3,134 | 0.146 |
| Discriminative Correlation Filter with Channel and Spatial Reliability | 2017 | 211 | 2,687 | 0.121 |
| Signature Schemes with Bounded Leakage Resilience | 2009 | 200 | 2,380 | 0.120 |
| Smashing the Gadgets: Hindering Return-Oriented Programming Using In-place Code Randomization | 2012 | 201 | 2,407 | 0.120 |
| A Leakage-Resilient Mode of Operation | 2009 | 210 | 2,566 | 0.117 |
Among well-connected papers (degree ≥ 200), the most clustered neighborhoods are systems-security and leakage-resilient-crypto papers, representing communities where everyone cites everyone. The contrast with a hub: SIFT has 46× the triangles of the top row but a coefficient of just 0.0005, because its 22,925 neighbors barely know each other.
Limits
No algorithm-specific limitations.
To dry-run validate relation metadata, column types, and options without execution, see gpu_validate_call.