Core Number
SQL function: cugraph_core_number
Compute graph core numbers.
Signature
cugraph_core_number(table_name [, src_col, dst_col [, weight_col [, options_json]]])
Allowed argument counts: 1, 3, 4, 5.
Quickstart
SELECT * FROM cugraph_core_number('target_edges')
Positional arguments
| Argument | Type | Required | Default | Notes |
|---|---|---|---|---|
table_name | Utf8 | yes | ||
src_col | Utf8 | no | src | |
dst_col | Utf8 | no | dst | |
weight_col | Utf8|null | no | accepted as an edge-column binding; native algorithm execution does not consume weights; semantic effect: none for this algorithm | |
options_json | Utf8 | no |
JSON options
| Option | Type | Default | Constraints | Description |
|---|---|---|---|---|
degree_type | Utf8 | "in_out" | one of "in", "out", "in_out" |
Graph construction options
Shared by all cuGraph functions, shown here with this function's defaults. The construction_policy option controls whether Nexus requests Python cuGraph-compatible edge normalization or bypasses it for raw libcugraph-style construction; see graph construction options for the full policy guide.
| Option | Type | Default | Constraints | Description |
|---|---|---|---|---|
construction_policy | Utf8 | "python_cugraph" | one of "python_cugraph", "raw_libcugraph" | Edge-list construction semantics used before calling libcugraph. |
directed | Boolean | false | Whether graph construction treats edges as directed. | |
renumber | Boolean | true | Whether graph construction may renumber external vertex identifiers internally. |
Output schema
| Column | Type | Nullable | Description |
|---|---|---|---|
vertex | Int64 | no | Vertex whose core number is reported. |
core_number | Int64 | no | Largest k value for which the vertex belongs to the graph k-core. |
These are the generic registry schemas. Run cugraph_validate_call for the concrete, table-specific output schema of a particular call.
Examples
This example runs on the citation network demo dataset.
How deep does the densest citation core go?
Core number measures how deep a vertex sits in recursively denser subgraphs
(with degree_type: "in_out", degree is in + out). Define the result as a
workspace view, find the deepest shell, and list who lives there:
CREATE VIEW cores AS
SELECT vertex, core_number FROM cugraph_core_number('citation_edges', 'src', 'dst');
SELECT MAX(core_number) AS deepest,
COUNT(*) FILTER (WHERE core_number = 70) AS members
FROM cores;
| deepest | members |
|---|---|
| 70 | 5,913 |
SELECT p.year, p.title
FROM cores c JOIN papers p ON p.paper_id = c.vertex
WHERE c.core_number = 70
ORDER BY p.n_citation DESC
LIMIT 6;
| year | title |
|---|---|
| 2004 | Distinctive Image Features from Scale-Invariant Keypoints |
| 2001 | Random Forests |
| 2011 | LIBSVM: A library for support vector machines |
| 1995 | The Nature of Statistical Learning Theory |
| 1995 | Support-Vector Networks |
| 1986 | A Computational Approach to Edge Detection |
The 70-core — 5,913 papers where everyone has at least 70 combined in/out edges to everyone else in the shell — is recognizably the machine-learning / computer-vision canon.
Limitations & notes
- dry-run validates table resolution, column presence, static dtypes, and options only
- dry-run does not scan edge data, construct a graph, or prove source-vertex existence
Validate before running
Always dry-run a call before executing it. Validation checks the function, table, columns, dtypes, and options without touching the GPU:
SELECT * FROM cugraph_validate_call(
'cugraph_core_number',
'your_edges_table',
'{"src_col":"src","dst_col":"dst"}'
);
See Discovery & validation for the full cugraph_validate_call contract.