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.
Signature
cugraph_triangle_count_all(table_name [, src_col, dst_col [, weight_col [, options_json]]])
Relation inputs
The first positional argument names a registered edge table or view (the edges role). Parenthesized relation subqueries are not accepted; metadata validation uses the same registered name.
Vertex ID types
The edges relation declares the accepted vertex-ID domains. Numeric calls preserve the existing numeric schema. When logical string support is declared, Utf8, LargeUtf8, and Utf8View endpoint columns share one logical domain; their vertex-identity outputs are canonicalized to Utf8.
| Domain | Accepted endpoint inputs | Output contract |
|---|---|---|
| Numeric edge endpoints | Int32, Int64 | The numeric output schema is used for numeric calls. |
| Logical string edge endpoints | Utf8, LargeUtf8, Utf8View | Vertex identity columns are canonicalized to Utf8; scores, distances, counts, coordinates, and opaque labels remain numeric. |
The native mapping type is Int64. Call-specific output schemas come 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
Scalar arguments & JSON options
Positional scalar arguments
src_col and dst_col name the edge endpoint columns; both are optional and default to src and dst.
| Argument | Type | Required | Default | Notes |
|---|---|---|---|---|
weight_col | Utf8|null | no | accepted as an edge-column binding; native algorithm execution does not consume weights; semantic effect: none for this algorithm |
JSON options
This function has no algorithm-specific options.
Graph construction options
This function builds an undirected graph by default (directed=false); all other graph construction options follow the shared defaults documented in Graph Construction Options.
Output schema
| 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; validate the 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 — 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('citation_edges', 'src', 'dst');
| 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. The full
scan, GPU graph build, and count return in about 0.6 s.
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('citation_edges', 'src', 'dst')),
deg AS (
SELECT vertex, in_degree AS degree
FROM cugraph_degrees_all('citation_edges', 'src', 'dst', NULL,
'{"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 — 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.
Limitations & lifecycle
No algorithm-specific limitations.
Validate before running
Dry-run validation checks registered relation metadata, column presence, static dtypes, and options only; it does not scan edge data, construct a graph, or prove source-vertex existence:
SELECT * FROM gpu_validate_call(
'cugraph_triangle_count_all',
'{"schema_version":1,"relations":{"edges":{"table":"target_edges"}},"options":{"src_col":"src","dst_col":"dst"}}'
);
See GPU Function Catalog API for the full gpu_validate_call contract.