Skip to main content
Note: APIs and configuration knobs may change in future releases.
This is useful when:
  • The result set is large and you want to limit memory usage on the client.
  • An application UI needs paged navigation through query results (tables, graphs, drilldowns).
  • You want simpler application logic for scrolling or pagination instead of manually managing LIMIT/OFFSET in SQL.
Pagination should be used through the StarTree Cloud Proxy service only.

How Pagination Work

A pagination-enabled query follows this lifecycle:
  1. A query is executed once on the cluster.
  2. The full result set is stored in a temporary result store.
  3. The first page of results is returned as part of the query response.
  4. The client then iterates through the results by calling pagination API with:
    • offset (start row)
    • numRows (page size)
  5. The client can:
    • Move forward or backward in the result set.
    • Change page size (numRows) between calls.

Result Store

The Result Store is responsible for storing query results for pagination-based access. Supported storage options:
  • memory
  • file (local filesystem or deep store such as S3/GCS, depending on configuration)
  • s3
  • gcs
Important
  • memory is not suitable for production.
  • memory and local filesystem storage do not work well with more than one broker, because pagination requests may be routed to brokers that do not hold the result set.

Configuration

Result Store Configuration

These configurations control where and how query results are stored.

Example: Local File Storage

Example: File Storage Using S3


Storage Cleaner

StarTree supports two cleanup mechanisms:

PaginationCleaner (Time-Based Cleanup)

PaginationCleaner is a periodic job that runs on the controller and deletes query results older than a configured TTL. It must be able to call all brokers and therefore needs appropriate authentication configuration.

Example:

Miscellaneous Settings

These settings control the default page size and expiry behavior for queries.

Quota-Based Storage Cleaner

The Quota-Based Storage Cleaner automatically cleans up temporary query result storage when disk usage exceeds a configured limit. This prevents broker nodes from running out of disk due to:
  • Long-running queries
  • Many concurrent cursor queries
  • Large result sets

Cleanup Behavior

  1. Removes expired results first.
  2. If storage is still above the target threshold, it cleans additional data based on size.
Note: Configuration for this feature can be updated without restarting the broker.

Example Configuration

Configuration Parameters


User APIs

Submit a Cursor-Enabled Query

Endpoint
Query Parameters
  • doPaginate (boolean): Enables cursor-based pagination when true.
  • numRows (int, optional): Number of rows to return in the first page.
Example Request
Example Response (truncated)

Iterate Over Results

Endpoint
Query Parameters
  • offset (int, required): Start offset of the page.
  • numRows (int, optional): Number of rows in this page. Defaults to pinot.broker.query.page.size.
Example Request
Example Response (truncated)
Cursor Fields
  • requestId: Unique ID for the query
  • offset: First record in current response
  • numRows: Number of rows in this page
  • nextOffsetParams: Pre-filled query parameters for the next page

Iterate Over Results for Local Filesystem

When using the broker’s local filesystem as the result store, the StarTree Cloud Proxy must route calls to the correct broker. Each response includes:
  • brokerHost
  • brokerPort
These must be included as request headers in subsequent pagination calls: Initial Query Request
Example Response Fragment
Subsequent Pagination Request

Retrieve Query Metadata

Endpoint
Example Request
Example Response (truncated) This returns the broker response metadata for the query, such as:

Admin APIs

List Stored Query Results

Endpoint
Example Request
Example Response (truncated)

Delete Query Results

Endpoint
Example Request
Example Response