Manage storage using tablespaces

note

Using tablespaces is one way to manage data storage costs with TimescaleDB. You can also use compression and to reduce your storage requirements.

To move chunks to a new tablespace, you first need to create the new tablespace and set the storage mount point. You can then use the API call to move individual chunks from the default tablespace to the new tablespace. The command also allows you to move indexes belonging to those chunks to an appropriate tablespace.

Additionally, move_chunk allows you reorder the chunk during the migration. This can be used to make your queries faster, and works in a similar way to the reorder_chunk command.

note

You must be logged in as a super user, such as the postgres user, to use the move_chunk() API call.

  1. List chunks that you want to move. In this example, chunks that contain data that is older than two days:

    1. SELECT show_chunks('conditions', older_than => INTERVAL '2 days');
  2. Move a chunk and its index to the new tablespace. You can also reorder the data in this step. In this example, the chunk called _timescaledb_internal._hyper_1_4_chunk is moved to the history tablespace, and is reordered based on its time index:

  3. You can verify that the chunk now resides in the correct tablespace by querying pg_tables to list all of the chunks on the tablespace:

    1. WHERE tablespace = 'history' and tablename like '_hyper_%_%_chunk';

    You can also verify that the index is in the correct location:

  1. SELECT move_chunk(
  2. chunk => i,
  3. destination_tablespace => '<TABLESPACE>')

After moving a chunk to a slower tablespace, you can move it back to the default, faster tablespace:

You can move a data chunk to the slower tablespace, but keep the chunk’s indexes on the default, faster tablespace:

  1. SELECT move_chunk(
  2. chunk => '_timescaledb_internal._hyper_1_4_chunk',
  3. destination_tablespace => 'history',
  4. index_destination_tablespace => 'pg_default',
  5. reorder_index => '_timescaledb_internal._hyper_1_4_chunk_netdata_time_idx'

You can also keep the data in pg_default but move the index to history. Alternatively, you can set up a third tablespace called history_indexes, and move the data to history and the indexes to .

In TimescaleDB 2.0 and later, you can use move_chunk with the job scheduler framework. For more information, see the .