In 19.1.0, PGX now ships again in two variants: distributed as well as shared-memory execution mode.
PGX 19.1.0 reintroduces distributed execution mode functionality and adds several new features compared to PGX 2.7.0 (the last version including distributed execution mode support).
Users can now query graphs using a subset of PGQL 1.1 features in PGX distributed execution mode. In brief, users can perform:
SELECT ... MATCH (a:person)-[e:likes]->(b:post) WHERE a.age > 18 AND a.group = b.group(directed); or
SELECT ... MATCH (a:person)-[e:follows]-(b:person)(any-directed)
GROUP BY, e.g.,
SELECT COUNT(*), MAX(a.age), AVG(a.age) MATCH (a:person)-[e:likes]->(b:post) WHERE a.age > 18
GROUP BY, e.g.,
SELECT a.age, AVG(a.income) ... GROUP BY a.age
SELECT a.age, ... ORDER BY a.age
For more information on what PGQL 1.1 features are supported in distributed execution mode, refer to PGQL in distributed execution mode overview page.
Users can now create, update and query data structures (sets, sequences and maps) in distributed execution mode. Sets and sequences can only store vertices or edges, and maps allow integers, longs, floats, doubles, boolean, vertices or edges as keys and values.
These structures are used in the same manner as in the shared memory version:
set = g.createVertexSet() set.add(vertex) set.remove(vertex) size = set.size()
Furthermore, a new algorithm is available in the distributed version:
inDegreeDistribution, which computes the distribution of number of incoming edges for all vertices.
Users can now load graphs in Two Tables RDBMS format in PGX distributed execution mode, by creating one database table for vertices, and one for edges, with the desired fields. For more information on this format, see Oracle Two Tables RDBMS.
In distributed execution mode, PGX now supports a subset of the graph builder API. This includes support for adding vertices and edges via the existing
Distributed execution mode now supports graph cloning as well as sharing/publishing of graphs, see details here.
PGX 19.1.0 introduces several new features also for the shared-memory execution mode.
In shared-memory execution mode, PGX now implements PGQL 1.2.
With 19.1.0, we also introduce some new features in beta mode, for which the syntax and semantics might change in future versions.
In shared-memory execution mode, PGX now supports loading and storing of heterogeneous graphs for a limited set of graph formats (e.g CSV and PGB).
All PGQL operators are supported as well as updating the graph using
GraphChangeSet. In addition, a limited set of Green-Marl algorithms are supported on heterogeneous graph, including reachability queries and Bellman-Ford.
Users can now update values of existing, session local properties through PGQL.
Please be aware that this is a beta feature, the exact syntax and semantics of the queries might change in the future.
The beta features can be turned on with an additional
/*beta*/ comment in the query.
The syntax is extended with update clauses that can contain one ore more assignments to properties. An update query returns null.
For example, the following query updates the value of property
age of every person named John.
MODIFY/*beta*/ g UPDATE v SET PROPERTY v.age = 42 FROM g MATCH (v:Person) WHERE v.name = 'John'
Properties can be updated via any variable matched by the pattern under the MATCH clause.
MODIFY/*beta*/ g UPDATE v, u SET PROPERTIES v.age = 42, u.weight = 3500 FROM g MATCH (v:Person) <-[:belongs_to]- (u:Car) WHERE v.name = 'John'
More information can be found on the PGQL specification page.
None of the already existing API methods support the update queries defined above. In order to run them, the following beta API methods (and their asynchronous versions) were defined:
PgqlResultSet executePgql(String query) PgxGraph cloneAndExecutePgql(String query) PgxGraph cloneAndExecutePgql(String query, String graphName)
Further details on the behavior, parameters and return value of the new methods can be found here.
In shared-memory execution mode, PGX introduces External Stores as a beta functionality for offloading graph properties to an external store such as Elasticsearch and enabling the use of an external store's specialized operations, e.g., text search.