add_columnstore_policy()

set a policy to automatically move chunks in a hypertable to the columnstore when they reach a given age.

Since 2.18.0

Create a job that automatically moves s in a to the after a specific time interval.

• Continuous aggregates:

  You first call ALTER MATERIALIZED VIEW to enable the on a , then create the job that converts your data to the with a call to add_columnstore_policy.

• Hypertables:

  When you create a using CREATE TABLE … WITH …, the default partitioning column is automatically the first column with a timestamp data type. Also, creates a columnstore policy that automatically converts your data to the , after an interval equal to the value of the chunk_interval, defined through compress_after in the policy. This columnar format enables fast scanning and aggregation, optimizing performance for analytical workloads while also saving significant storage space. In the conversion, s are compressed by up to 98%, and organized for efficient, large-scale queries.

  You can customize this policy later using alter_job. However, to change after or created_before, the compression settings, or the the policy is acting on, you must remove the columnstore policy and add a new one.

  You can also manually convert s in a to the .

When is enabled, bloom filters are enabled by default, and every new has a bloom index. Bloom indexes are not retrofitted, existing s need to be fully recompressed to have the bloom indexes present. If you converted s to using v2.19.3 or below, to enable bloom filters on that data you have to convert those s to the , then convert them back to the .

To view the policies that you set or the policies that already exist, see informational views.

A policy is applied on a per- basis. If you remove an existing policy and then add a new one, the new policy applies only to the s that have not yet been converted to . The existing s in the remain unchanged. This means that s with different settings can co-exist in the same .

Samples

To create a job:

• Enable

  For efficient queries on data in the columnstore, remember to segmentby the column you will use most often to filter your data.

  • Use ALTER MATERIALIZED VIEW for a

    ALTER MATERIALIZED VIEW assets_candlestick_daily SET (
       timescaledb.enable_columnstore = true,
       timescaledb.segmentby = 'symbol');
    

  • Use CREATE TABLE for a . The columnstore policy is created automatically.

    CREATE TABLE crypto_ticks (
       "time" TIMESTAMPTZ,
       symbol TEXT,
       price DOUBLE PRECISION,
       day_volume NUMERIC
    ) WITH (
      tsdb.hypertable,
      tsdb.segmentby='symbol',
      tsdb.orderby='time DESC'
    );
    

    For v2.23.0 and higher, the table is automatically partitioned on the first column in the table with a timestamp data type. If multiple columns are suitable candidates as a partitioning column, throws an error and asks for an explicit definition. For earlier versions, set partition_column to a time column.

    If you are self-hosting v2.20.0 to v2.22.1, to convert your data to the after a specific time interval, you have to call add_columnstore_policy after you call CREATE TABLE

    If you are self-hosting v2.19.3 and below, create a relational table, then convert it using create_hypertable. You then enable with a call to ALTER TABLE.

• Add a policy to move s to the at a specific time interval

  For example:

  • 60 days after the data was added to the table:

    CALL add_columnstore_policy('crypto_ticks', after => INTERVAL '60d');
    

  • 3 months prior to the moment you run the query:

    CALL add_columnstore_policy('crypto_ticks', created_before => INTERVAL '3 months');
    

  • With an integer-based time column:

    CALL add_columnstore_policy('table_with_bigint_time', BIGINT '600000');
    

  • Older than eight weeks:

    CALL add_columnstore_policy('cpu_weekly', INTERVAL '8 weeks');
    

  • Control the time your policy runs:

    When you use a policy with a fixed schedule, uses the initial_start time to compute the next start time. When finishes executing a policy, it picks the next available time on the schedule, skipping any candidate start times that have already passed.

    When you set the next_start time, it only changes the start time of the next immediate execution. It does not change the computation of the next scheduled execution after that next execution. To change the schedule so a policy starts at a specific time, you need to set initial_start. To change the next immediate execution, you need to set next_start. For example, to modify a policy to execute on a fixed schedule 15 minutes past the hour, and every hour, you need to set both initial_start and next_start using alter_job:

    select * from alter_job(1000, fixed_schedule => true, initial_start => '2025-07-11 10:15:00', next_start =>
    '2025-07-11 11:15:00');
    

• View the policies that you set or the policies that already exist

  SELECT * FROM timescaledb_information.jobs
  WHERE proc_name='policy_compression';
  

  See timescaledb_information.jobs.

Arguments

Calls to add_columnstore_policy require either after or created_before, but cannot have both.

Name	Type	Default	Required	Description
hypertable	REGCLASS	-	✔	Name of the or to run this job on.
after	INTERVAL or INTEGER	-	✖	Add s containing data older than now - {after}::interval to the . Use an object type that matchs the time column type in hypertable: TIMESTAMP, TIMESTAMPTZ, or DATE: use an INTERVAL type. Integer-based timestamps : set an integer type using the integer_now_func. after is mutually exclusive with created_before.
created_before	INTERVAL	NULL	✖	Add s with a creation time of now() - created_before to the . created_before is Not supported for s. Mutually exclusive with after.
schedule_interval	INTERVAL	12 hours when chunk_time_interval >= 1 day for hypertable. Otherwise chunk_time_interval / 2.	✖	Set the interval between the finish time of the last execution of this policy and the next start.
initial_start	TIMESTAMPTZ	The interval from the finish time of the last execution to the next_start.	✖	Set the time this job is first run. This is also the time that next_start is calculated from.
next_start	TIMESTAMPTZ	-	✖	Set the start time of the next immediate execution. It does not change the computation of the next scheduled time after the next execution.
timezone	TEXT	UTC. However, daylight savings time(DST) changes may shift this alignment.	✖	Set to a valid time zone to mitigate DST shifting. If initial_start is set, subsequent executions of this policy are aligned on initial_start.
if_not_exists	BOOLEAN	false	✖	Set to true so this job fails with a warning rather than an error if a policy already exists on hypertable