titlesidebar_labeldescription
Designated timestamp
Designated timestamp
How designated timestamps are implemented and why it is an important functionality for time series.

QuestDB offers the option to elect a column as a designated timestamp. This allows you to specify which column the tables will be indexed by in order to leverage time-oriented language features and high-performance functionalities.

:::info

Checking if tables contain a designated timestamp column can be done via the tables() and table_columns() functions which are described in the meta functions documentation page.

:::

Properties

  • Only a column of type timestamp can be elected as a designated timestamp.
  • Only one column can be elected for a given table.
  • A designated timestamp is elected either:

Out-of-order policy

As of version 6.0.0, QuestDB supports ingestion of records which are out-of-order (O3) by time. Configuring how often out-of-order data is committed is done via commit lag and row count.

:::info

In versions prior to 6.0.0, when a column was elected as a designated timestamp, it would enforce an order policy and O3 inserts would be rejected. In other words, new timestamp values needed to be greater than or equal to the most recent timestamp in the column.

:::

Advantages

Electing a designated timestamp allows you to:

  • Partition tables by time range. For more information, see the partitions reference.
  • Use time series joins such as ASOF JOIN. For more information, see the JOIN reference.