What are the built-in index that TigerGraph create per default?

Hi,

as it sees to be either scattered or implicit in the doc and the forum, i wonder if someone could sum it up in one place

What are the built-in index that TigerGraph create per default and what complexity do they provide ?

My understanding/guess so far is:

Vertex Type (come with the creation of the schema, also known as Label in the industry)

Primary Key (must be defined in the old syntax)

“Vertex-centric Index” (Graph in structure, but comes with the direction of the relationship in the schema)

On the last index not sure if the name is appropriate here, but the idea is that the graph in structure allow to follow the links. Also, direction of the relationship matter when creating the schema, without a direction that micro index would not exist. Hence the question, is an un-directed relation equivalent to having a bi-directional relationship index wise ?

There are no implicit indexes. There is a typed list of edges outgoing from a vertex, which we don’t call indexes as they aren’t sorted or anything, though we do hold some statistics against them. Possibly just a matter of definition here.

Bidirectional and reverse edges (they are physically the same) are transactionally managed, so if you insert one, then the other is equivalently inserted. Similarly for updates and deletes.

We do offer a single alternative index, but that is explicit.

So yes, a vertex type is like a label, but we enforce schema, it isn’t dynamic or composable.

The primary key is always defined in the schema for both versions of the syntax, and is the retrieval key. It is held in a global dictionary, and offers very fast point access. No range queries or fuzzy matching, and doesn’t work with “WHERE” filters.

“Vertex-centric index”, not really, not in the same way that it is implemented in Janus/Tinkerpop. We do have vertex-attached edge lists, which could be seen as a degenerate index I guess, but only on outward edges. Some implementations of Tinkerpop work this way (Datastax’ most recent engine for example), but most use a separate edge dictionary which are exactly forward and reverse indexes.

For us, undirected edges are implemented by putting edges on both the source and target. Similarly where a reverse edge is specified.

Hopefully that clarifies a little!

1 Like

@Richard_Henderson thank you it helps. I will still need to group things into points, and make sure that i got everything right by confirming it with you.