PostgreSQL TimescaleDB Settings
PostgreSQL TimescaleDB settings affect the stability and performance of the database cluster. When creating a cluster, default values are applied. These defaults are optimized for high performance and vary depending on the cluster configuration and the version of PostgreSQL TimescaleDB.
You can:
- view the default setting values and change them when creating a cluster;
- or view settings and change them in an already created cluster.
We recommend changing setting values only when necessary—incorrect values can make the cluster inoperable or reduce its performance.
When scaling a cluster, some settings are automatically replaced with their default values. The list of such settings can be found in the Automatic settings changes when scaling a cluster subsection.
View settings
You can view the list of settings available for changes when creating a cluster or changing settings.
If you have changed the settings, you can separately view a list of settings whose values differ from the default values.
A detailed description of all settings can be found in the Server Configuration section of the PostgreSQL documentation.
- In the Dashboard, on the top menu, click Products and select Managed Databases.
- Open the Active tab.
- Open the cluster page → Settings tab.
- In the DBMS Settings block, click Change.
- Optional: to view only those settings for which you have changed the default value, select the Show changed parameters checkbox.
- View settings.
Change settings
We recommend changing setting values only when necessary—incorrect values can make the cluster inoperable or reduce its performance.
Changing some settings will cause the cluster to reboot automatically, making it unavailable during the process. The reboot begins immediately after saving the changes. The list of such settings can be found in the List of settings that require a reboot subsection.
- In the Dashboard, on the top menu, click Products and select Managed Databases.
- Open the Active tab.
- Open the cluster page → Settings tab.
- In the DBMS Settings block, click Change.
- Specify new values.
- Click Save.
List of settings that require a restart
autovacuum_freeze_max_age;autovacuum_max_workers;autovacuum_multixact_freeze_max_age;huge_pages;max_connections;max_files_per_process;max_locks_per_transaction;max_logical_replication_workers;max_pred_locks_per_transaction;max_prepared_transactions;max_wal_senders;max_worker_processes;old_snapshot_threshold;pg_stat_statements.max;shared_buffers;timescaledb.max_background_workers;track_activity_query_size.
Automatic settings adjustment during cluster scaling
Database settings have permissible value ranges. If, during cluster scaling, setting values exceed the permissible ranges, they are automatically replaced with default values so that the cluster can continue to operate.
Once the cluster is scaled and enters the ACTIVE status, you can change the settings and set new values.
List of settings whose values are reverted to default when scaling the cluster:
autovacuum_max_workers;effective_cache_size;maintenance_work_mem;max_parallel_workers;max_wal_size;max_worker_processes;shared_buffers;vacuum_cost_limit;work_mem.
Configuring huge_pages
In Managed Databases, PostgreSQL TimescaleDB you can enable and disable Huge Pages using the huge_pages setting.
Huge Pages is a memory management technology that allows using memory pages with a larger size than standard ones. The size of standard memory pages is 4 KB. Once the huge_pages setting is enabled, 2 MB memory pages become available. You can use Huge Pages, for example, for shared memory buffers (shared buffers). Thanks to this technology, you can reduce compute resource overhead: vCPU and RAM.
The huge_pages setting is available for PostgreSQL TimescaleDB version 15 and higher.
Possible values are on and off. The default value is off. If you change this setting, the cluster will automatically restart and will be unavailable during the reboot. The restart will begin immediately after saving the changes.
If the huge_pages setting is enabled, but shared memory limits do not allow using Huge Pages, the cluster will enter an ERROR status. In this case, we recommend reducing the value of the shared_buffers.