SQL/PGQ - Kinetica Docs

SQL/PGQ can be used to query an existing graph using the supported subset of the Cypher Query Language syntax. A graph query can also be used within a SQL query to join the graph result to a data model.

GRAPH [<schema name>.]<graph name>
MATCH <match expr>
[WHERE <filter list>]
RETURN <return list>
[ORDER BY <ordering list>]
[LIMIT <num rows>]

SELECT * FROM GRAPH_TABLE
(
    GRAPH [<schema name>.]<graph name>
    MATCH (<match expr>)
    [WHERE <filter list>]
    RETURN <return list>
    [ORDER BY <ordering list>]
    [LIMIT <num rows>]
)

Parameters

Name of the schema containing the graph; if no schema is specified, the graph will be looked for in the user’s default schema

Name of the graph to query

Any supported Cypher MATCH expression.For example, to query for relationships with the following criteria:

Starting node can be referred to with js in the rest of the graph query
Starting node has both User & Admin labels
Starting node has property values of Joe & Smith for properties first_name & last_name, respectively
Ending node is one hop away from the starting node
Ending node has a label of User

use this MATCH expression:

(js:User:Admin {first_name: 'Joe', last_name: 'Smith'})-[]->(:User)

Individual labels, property names, and column names can be double-quoted if needed to avoid conflicts with the Cypher query syntax:

(n:"SYSTEM ADMIN":"BUSINESS ANALYST" {"last name": 'Smith'})

Expression Description

() Node Matcher Matches any node.

(<ref>) Node Reference Matches any node; matched nodes are able to be referenced as <ref> in the rest of the match statement.

(:<label>)

Node Label Matcher Matches any node with a label of <label>; any number of labels can be combined to form a composite restriction:

Combination	Node Must Have
`:<label1>:<label2>`	`<label1>` and `<label2>`
`:<label1>\|<label2>`	`<label1>` or `<label2>`

({<name>: <value>})

Node Property Matcher Matches any node with a property <name> whose value is <value>; any number of properties can be combined to form a composite restriction requiring a node to have all the specified property values; e.g.:

{section: 12, last_name: ‘Smith’}

Mutually exclusive with the Node WHERE Clause Matcher

(WHERE <expression>)

Node WHERE Clause Matcher Matches any node that meets the restrictions of the given <expression>; this is a standard SQL WHERE clause that can reference a node’s ID, properties, or labels, but cannot include sub-query constructs (ANY/ALL/IN/EXISTS); e.g.:

WHERE node <= 5 AND CONTAINS(‘MANAGER’, label)

Mutually exclusive with the Node Property Matcher

[] Edge Matcher Matches any edge.

[<ref>] Edge Reference Matches any edge; matched edges are able to be referenced as <ref> in the rest of the match statement.

[:<label>]

Edge Label Matcher Matches any edge with a label of <label>; any number of labels can be combined to form a composite restriction:

Combination	Relationship Must Have
`:<label1>\|<label2>`	`<label1>` or `<label2>`

Each relationship can have only 1 label.

({<name>: <value>})

Edge Property Matcher Matches any edge with a property <name> whose value is <value>; any number of properties can be combined to form a composite restriction requiring an edge to have all the specified property values; e.g.:

{manages: true, years: 3}

Mutually exclusive with the Edge WHERE Clause Matcher

[WHERE <expression>]

Edge WHERE Clause Matcher Matches any edge that meets the restrictions of the given <expression>; this is a standard SQL WHERE clause that can reference an edge’s label, node IDs, or properties, but cannot include sub-query constructs (ANY/ALL/IN/EXISTS); e.g.:

WHERE years <= 5 AND label = ‘MANAGES’

Mutually exclusive with the Edge Property Matcher

()-[]->()

Path Matcher Matches any node connected via an edge to another node. Relationships must be specified with a directional arrow indicating the direction of the relationship; however, the direction restriction specified will be ignored if the following hint is given with the query:

KI_HINT_QUERY_GRAPH_ENDPOINT_OPTIONS(multi_paths,true)

()-[]->{n[,m]}() Path Repeater Matches any node connected via n number of edges to another node. If the optional m is specified, the number of edges must be between n and m, inclusive. Any restriction on the edge is in effect for all n to m intermediate edges between the start and end nodes.

Filter expressions to apply to the entire graph query. The expressions can include columns on which the graph is based, not just names & labels available in the graph itself.

Expressions referencing graph names, graph labels, or supporting graph table columns to use as the result set for the graph query. Each expression must include a unique alias.

Ordering expression(s) to apply to the result set. Columns referenced do not have to be present in the RETURN clause.

Maximum number of records to return in the result set.

Examples

For example, to query for managers in department 6 making more than $150,000:

Node Query Example

GRAPH employee_graph
MATCH (a:MANAGER {"dept_id": 6})
WHERE salary > 150000
RETURN a
ORDER BY a.node

To query for employees who have had the employee with ID #2 as their manager for three years or more:

Edge Query Example

GRAPH employee_graph
MATCH ()-[b:MANAGES {node1: 2}]->()
WHERE years >= 3
RETURN b
ORDER BY b.node1, b.node2

To query for employees who work with each other but have different managers:

Path Query Example

GRAPH employee_graph
MATCH (m1)-[r1:MANAGES]->(e1)-[ww:"WORKS WITH"]->(e2)<-[r2:MANAGES]-(m2)
WHERE m1 != m2
RETURN m1, e1, e2, m2
ORDER BY m1.node, e1.node, e2.node

To query with variable hops to find all managers in the management chain for employee with ID #14 (or at most, 10 levels of managers above the employee):

Variable Hop Path Query Example

GRAPH employee_graph
MATCH (m)-[r1:MANAGES]->{1,10}(e {node: 14})
RETURN m, e
ORDER BY m.node

To use a SQL/PGQ query as a subquery, joining the result with another table:

SQL/PGQ Query as a Subquery Example

SELECT m_id, m_fullname, e_id, e_fullname, ap.prize
FROM GRAPH_TABLE
	(
		GRAPH employee_graph
		MATCH (m)-[r:MANAGES]->(e)
		RETURN m.node AS m_id, m.full_name AS m_fullname, r.years, e.node AS e_id, e.full_name AS e_fullname
	) eg
JOIN anniversary_prize ap
	ON ap.year = eg.years
ORDER BY m_id, e_id

Limitations & Suggestions

Graph must be created via SQL and must not be altered, either via SQL or a native API.
Graph must be created with all nodes having:
- the same identifier combination
- a single column identifier
- the same data type
- the same nullability—when creating a graph with constant values, the REMOVE_NULLABLE function can be used to make the value NOT NULL
Graph should be created with Node & edge INPUT_TABLES as regular tables or materialized views instead of queries or logical views. This will reduce the complexity of query plans involving joins on the graph source data, and improve the performance of SQL/PGQ queries overall.
Graph should be created with the add_table_monitor option if the data in the graph support tables are expected to change, as those changes would otherwise cause the graph and its tables to go out-of-sync, returning wrong results in SQL/PGQ queries. If the data in the support tables will not change, this option can be omitted.
Querying a graph in this manner generally requires that, when the graph being queried was created, no correlated subqueries were used as part of any input table queries. However, a materialized view can be created containing the query, and then the view can be used in place of the query as an input table.

​Parameters

​Examples

​Limitations & Suggestions

Parameters

Examples

Limitations & Suggestions