Query table configuration

This guide discusses how to control various QueryTable features that affect your Deephaven tables' latency and throughput.

QueryTable

QueryTable is Deephaven's primary implementation of our Table API.

The QueryTable has the following user-configurable properties:

Each property is described below, roughly categorized by similarity.

Memoization

Deephaven utilizes memoization for many table operations to improve performance by eliminating duplicate work. See Query Memoization for more details.

It can be beneficial to disable memoization when benchmarking or testing, as memoized results can hide true operational costs and skew performance metrics.

Redirection

Deephaven Tables maintain a 63-bit keyspace that maps a logical row in row-key space to its data. Many of Deephaven's column sources use a multi-level data layout to avoid allocating more resources than necessary to fulfill operational requirements. See selection method properties for more details.

Redirection is a mapping between a parent column source and the resulting column source for a given operation. A sorted column, for example, is redirected from the original to present the rows in the targeted sort order. Redirection may also flatten from a sparse keyspace to a flat and dense keyspace.

DataIndex

A Deephaven DataIndex is an index that can improve the speed of filtering operations.

Pushdown predicates with where

Pushdown predicates refer to the mechanism whereby filtering conditions are applied as early as possible, ideally at the data source (e.g., Parquet or other columnar formats), before loading data into the system. By annotating source reads with predicates, the engine pulls in only the rows that satisfy the conditions, significantly reducing I/O and improving performance.

The two *ForWhereThreshold properties are cost heuristics rather than on/off switches. Scanning a data index table or a dictionary costs time proportional to its size, so the engine only does so when that structure is small relative to the rows it can eliminate. When the index table or dictionary exceeds its threshold, the engine does not use it, and the rows are filtered normally. Raise the value toward 1.0 to apply these optimizations to columns with more distinct values, or set it to 0 to effectively disable the technique.

For more details, see Predicate pushdown filtering.

Parallel processing with where

Parallelism for where operations is not enabled until the parent's size exceeds QueryTable.parallelWhereRowsPerSegment rows. This avoids the overhead of using threads for small operations. For tables larger than this threshold, the where operation uses a fixed number of parallel segments defined by QueryTable.parallelWhereSegments. These parameters can be tuned to avoid unnecessary parallelism when the overhead exceeds potential gains.

Parallel processing with select

The QueryTable operations select and update have performance enhancements that try to take advantage of parallelism during two separate phases of each table operation invocation. The first opportunity for parallelism is on the initial creation of the table. The engine will parallelize the initial computation of the resulting table state. The second opportunity for parallelism is when the operation's parent-table listener is notified that the parent was updated.

Parallelism for select operations is not enabled until the parent's size exceeds QueryTable.minimumParallelSelectRows rows. This can be tuned to avoid unnecessary parallelism (e.g., when the overhead exceeds potential gains).

Parallel snapshotting

Barrage clients, including our JavaScript implementation used on the web, fulfill subscription requests by snapshotting the required rows and columns in addition to listening for relevant changes when the table is refreshing. Parallel snapshotting is a feature that parallelizes this process across columns. If those columns are slow to access then parallel snapshotting will greatly reduce latency. However, parallel snapshotting may open many file handles to the same data source.

Parallel snapshotting is not enabled until the snapshot size exceeds QueryTable.minimumParallelSnapshotRows rows. This can be tuned to avoid unnecessary parallelism when the overhead exceeds potential gains.

Ungroup operations

The ungroup table operation can expand one row into multiple rows. QueryTable.minimumUngroupBase controls the initial allocation used by ungroup.

SoftRecycler configuration

Deephaven uses SoftRecycler objects to manage memory for array and sparse array column sources. These column sources must maintain previous values during an update graph cycle. Rather than allocating fresh memory on each cycle, when memory is needed to record previous values it is borrowed from the recycler and returned at the end of the update cycle. These pools can improve performance and reduce garbage collection pressure.

A recycler's capacity is the most arrays it holds at once. Each recycler adapts its capacity to its traffic: it starts at a configured capacity, grows when a cycle needs more arrays than it holds, and shrinks back toward the configured capacity when arrays go unused, but never below it and never above a configured maximum. Both values can be set per element type, and the growth and shrink rules are described below.

Array column source recyclers

Array-backed column sources (dense arrays) use SoftRecyclers to manage blocks of data for each primitive type. Each capacity property sets the capacity a recycler starts with and never shrinks below, and each maximumCapacity property sets the most it grows to.

The "in use" bitmaps, which record which entries of a block hold a previous value, have a recycler of their own that every type shares. Its capacity and maximum are the sums of the types' values, and it has no properties.

Sparse array column source recyclers

Sparse array column sources use a multi-level hierarchical structure and maintain separate recyclers at each level. Each level can be configured independently to optimize memory usage for your access patterns. As for array column sources, each capacity property sets the capacity a recycler starts with and never shrinks below, and each maximumCapacity property sets the most it grows to.

The "in use" bitmaps have a recycler of their own at each level, which every type shares. Each one's capacity and maximum are the sums of the types' values at that level, and none has properties.

How recyclers grow and shrink

A recycler grows during the cycle that needs more arrays than it holds. When a cycle returns arrays to a full recycler, the recycler turns them away and counts them. Each later borrow that finds the recycler empty is an array it could have kept, so the recycler grows by one for each such borrow until the count is spent. Growth therefore never exceeds what some cycle used, and it never exceeds the configured maximum.

A recycler shrinks at the end of each window. A window is sized to span a whole cycle of every update graph in the process: it lasts SoftRecycler.windowMargin times the longest interval between consecutive cycle starts among the update graphs, but no less than SoftRecycler.windowMillis and no more than SoftRecycler.maximumWindowMillis. If the recycler never emptied during the window, the arrays it never lent out were not needed, and it discards the fraction of them set by SoftRecycler.shrinkFraction, never shrinking below its configured capacity.

Windows end only when an update graph starts a cycle. In a process whose update graphs never cycle, recyclers never shrink. The recyclers hold their arrays through soft references, so the garbage collector reclaims them under memory pressure in any case.

Tuning recyclers

Because recyclers adapt, most workloads need no tuning. The configured capacity sets how many arrays a recycler keeps through quiet periods, and the maximum bounds how many it keeps through busy ones.

• Workloads that alternate busy and quiet cycles: Raise SoftRecycler.windowMillis, or set SoftRecycler.shrinkFraction to 0, so that a recycler keeps what a busy cycle needed through the quiet cycles between.
• Memory-constrained environments: Set a maximumCapacity to bound what a recycler holds, or raise SoftRecycler.shrinkFraction toward 1 to discard unneeded arrays sooner.
• Type-specific tuning: If certain types dominate, raise their capacity or maximum while reducing others.

Stateless by default

These flags enable the engine to assume more often that a given Filter or Selectable can be executed in parallel (unless the Filter or Selectable is marked serial or has barriers interface).

Related documentation

• QueryTable JavaDocs
• Table API
• Incremental update model
• Query Memoization
• Data indexes
• Parallelizing queries