All Products
Search
Document Center

ApsaraDB RDS:Set the parameters of an RDS for PostgreSQL instance

Last Updated:Aug 06, 2025

You can modify the parameters of an RDS for PostgreSQL instance in the console or by calling an API operation to improve performance or meet specific business requirements. You can also query the parameter modification history.

Usage notes

  • Modifying some parameters triggers an instance restart. Your instance restarts immediately after you modify the parameters and click Submit Parameters. To determine if modifying a parameter will trigger a restart, check the value in the Restart column on the Editable Parameters page in the console. If the instance restarts, your application will be disconnected. Make sure that your business is prepared for the instance restart. Proceed with caution.

  • When you modify the value of a parameter in the console, refer to the Value Range column on the Editable Parameters tab.

  • When you modify the following parameters on the primary instance, the changes are synchronized to all associated read-only instances.

    wal_level, max_replication_slots, max_wal_senders, max_locks_per_transaction, max_worker_processes, max_prepared_transactions

  • When you modify a parameter, the system attempts to apply the change. If the new parameter value is invalid or causes the instance to fail, the modification is rolled back and the result is marked as Failed. You can view the modification result in the Effective column on the Parameter Modification History tab.

  • The log_statement parameter cannot be modified directly. You can change the value of this parameter by enabling or disabling SQL Explorer and Audit in the SQL Explorer and Audit console.

Modify parameter values

  1. Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the instance ID.

  2. In the left navigation pane, click Parameters.

  3. On the Editable Parameters tab, find the parameter that you want to modify. You can modify parameters one at a time or in batches. The following steps describe how to perform these operations:

    • Modifying a single parameter

      1. Click the icon next to the parameter that you want to modify.

      2. Enter a destination value and click OK.

      3. Click Submit Parameters.

      4. In the dialog box that appears, specify when the new value takes effect. You can select Apply Immediately, Apply Within Maintenance Window, or Apply At A Specified Time. Then, click OK.

    • Modifying parameters in batches

      1. Click Export Parameters to download the parameter file to your computer.

      2. Open the parameter file and modify the parameter values.

      3. Click Import Parameters.

      4. In the Import Parameters window, paste the parameters and their values to modify, and then click OK.

      5. Confirm the modifications in the parameter list and click Submit Parameters.

      6. In the dialog box that appears, select when the new values take effect. You can select Apply Immediately, Apply Within Maintenance Window, or Apply At A Specified Time, and then click OK.

    Note

    On the Scheduled Parameter Modification Tasks tab, you can view parameter modification tasks that are set to Apply Within Maintenance Window or Apply At A Specified Time.

Query parameter modification history

  1. Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the instance ID.

  2. In the left navigation pane, click Parameters.

  3. Click the Parameter Modification History tab.

  4. Select a time range and click OK.

Parameter expressions

You can set parameters using expressions. If you set an instance type-related parameter to an expression, the parameter value dynamically changes when you change the instance type. This ensures that the parameter value remains applicable to the new instance type.

The following table describes the supported expression syntax.

Category

Usage notes

Example

Parameters

The following parameters support expressions:

Parameters that support expressions

  • work_mem: specifies the amount of memory that is used by internal sorting operations and hash tables before data is written to temporary files.

  • maintenance_work_mem: sets the maximum amount of memory that can be used for maintenance operations, such as VACUUM and CREATE INDEX.

  • autovacuum_work_mem: specifies the maximum amount of memory that each autovacuum worker process can use.

  • max_parallel_workers: sets the maximum number of workers that the system can support for parallel operations.

  • max_parallel_workers_per_gather: sets the maximum number of workers that can be started by a single Gather or Gather Merge node.

  • effective_cache_size: sets the preset value of the optimizer for the total size of the data cache.

  • autovacuum_max_workers: specifies the maximum number of autovacuum processes that can run at the same time, except for the autovacuum launcher.

  • max_wal_size: sets the size of the write-ahead logging (WAL) files that trigger a checkpoint.

  • min_wal_size: sets the minimum size of WAL files to recycle. As long as WAL disk usage remains below this setting, old WAL files are always recycled for future use at a checkpoint, rather than deleted.

  • temp_file_limit: specifies the maximum disk space that a process can use for temporary files, such as sort and hash temporary files, or the storage file for a held cursor.

  • wal_buffers: sets the size of disk-page buffers in shared memory for WAL, which is the amount of shared memory used for WAL data that is not written to a disk.

  • max_parallel_maintenance_workers: sets the maximum number of parallel workers for a CREATE INDEX operation.

  • max_worker_processes: sets the maximum number of concurrent worker processes.

Note

The max_parallel_maintenance_workers parameter is supported only for RDS PostgreSQL 11.0 and later.

effective_cache_size

Variables

  • AllocatedStorage: the storage capacity of the instance type in MB. The value of this variable is an integer.

  • DBInstanceClassMemory: the memory size of the instance type in bytes. The value of this variable is an integer.

  • DBInstanceClassCPU: the number of CPU cores of the instance type. The value of this variable is an integer.

  • DBInstanceClassConnections: the maximum number of connections of the instance type. The value of this variable is an integer.

Note

For more information about the instance types and the storage capacity, memory size, number of CPU cores, and maximum number of connections that are supported by each instance type, see Primary RDS for PostgreSQL instance types.

effective_cache_size={DBInstanceClassMemory/16384}

Operators

  • Expression syntax: An expression is enclosed in braces ({}).

  • Division operator (/): divides a dividend by a divisor and returns an integer quotient. If the quotient is a decimal, the system does not round the quotient but truncates the decimal part. The dividend and divisor can be decimals.

  • Multiplication operator (*): multiplies two multipliers and returns an integer product. If the product is a decimal, the system does not round the product but truncates the decimal part. The two multipliers can be decimals.

Functions

  • The GREATEST() function returns the largest value in a list of integers or parameter formulas.

  • The LEAST() function returns the smallest value in a list of integers or parameter formulas.

  • The SUM() function adds the values of specified integers or parameter formulas.

max_parallel_workers={GREATEST(DBInstanceClassCPU*3/4, 8)}

References