We were not linking it to the documentation as we did not consider it a very easy read, but we will think about it, and also because of the differences you have also found here.

IX is Indexer. It Essentially stores tuples in some kind of bucketed hash lookup. So if there are 4 columns, then indexing tuples by mask [0,1]/4 means that they are sorted into buckets based on their first two elements. The most important reason to have such a node is to add IX nodes as parents to join nodes. If a new tuple arrives at the join node from one parent, then the join node can ask the other parent IX to look up which tuples are to be joined against the newly inserted one (due to having the same join key), and join them with the original update, and propagate this as its output delta.[/li]

From the point of view of the join node, an Aggregator Indexer has the same interface as regular IXers. But instead of returning all tuples in the bucket, it will return a single tuple with their aggregate value. This can be a neutral value if the bucket is empty (e.g. 0 in case of sum).[/li]

As a minor and irrelevant performance optimization, and also for legacy reasons, counting is implemented a bit differently than other aggregators. Hence the CountNode. [/li]

Dispatch nodes and Discriminator Buckets: it is a common use case to divide a big relation based on constant values of one column. E.g. if you have a pattern operation(umlClass, operationName, operationType, operationVisibility), then you can get all private operations by taking the subset of tuples where the last column is VisibilityKind::PRIVATE, similarly for PUBLIC, DEFAULT etc. Under the hood, a dispatch node receives all tuples of the operation, and dispatches them across many child nodes (the discriminator buckets) based on the value of a certain column. Internally, it just has a simple hash map as "routing table" that assigns the corresponding bucket node for each value of the column that was actually used in a pattern as a filtering constant.[/li]