Configuration

Overview of all modified and new server configuration options based on PostgreSQL.

These settings control the resource consumption of the database server.

• threaded_execution (boolean)

  Controls whether to enable the multithreaded Postgres model. In Redrock Postgres, the multithreaded Postgres model enables Postgres processes on UNIX and Linux to run as operating system threads in separate address spaces.

  On Windows, session related backend processes always use threaded execution; the remaining background processes run as operating system processes. Thus, an “Postgres process” is not always equivalent to an “operating system process.”

There are several WAL-related configuration parameters that affect database performance.

• data_checksums (boolean)

  Determines whether to calculate a checksum when writing a data block (a number calculated from all the bytes stored in the block) and store it in the page header of every data block when writing it to disk. Checksums are verified when a block is read - only if this parameter is on and the last write of the block stored a checksum. Besides, Postgres also verifies the checksum before a change application from update/delete statements and recomputes it after the change is applied. In addition, Postgres gives every WAL record a checksum before writing it to disk.

  If this parameter is set to off, data checksums are turned off.

  Checksums allow Postgres to detect corruption caused by underlying disks, storage systems, or I/O systems. Turning on data checksums causes only an additional 1% to 2% overhead. If set, checksums are calculated for all objects, in all databases. All checksum failures will be reported in the pg_stat_database view.

These parameters control server-wide statistics collection features. When statistics collection is enabled, the data that is produced can be accessed via the pg_stat and pg_statio family of system views. Refer to Statistics Collector for more information.

• track_wait_events (boolean)

  Enables the collection of information on the wait events occured in each session, include occured times and timing information. This parameter is on by default. Note that even when enabled, this information is not visible to all users, only to superusers and the user owning the session being reported on, so it should not represent a security risk. Only superusers can change this setting.

These settings control the behavior of the autoanalyze feature. Refer to Section 24.1.6 for more information. Note that many of these settings can be overridden on a per-table basis; see Storage Parameters.

• autoanalyze (boolean)

  Controls whether the server should run the autoanalyze launcher daemon. This is on by default; however, track_counts must also be enabled for autoanalyze to work. This parameter can only be set in the postgresql.conf file or on the server command line; however, autoanalyzing can be disabled for individual tables by changing table storage parameters.

• log_autoanalyze_min_duration (integer)

  Causes each action executed by autoanalyze to be logged if it ran for at least the specified amount of time. Setting this to zero logs all autoanalyze actions. -1 (the default) disables logging autoanalyze actions. If this value is specified without units, it is taken as milliseconds. For example, if you set this to 250ms then all automatic analyzes that run 250ms or longer will be logged. In addition, when this parameter is set to any value other than -1, a message will be logged if an autoanalyze action is skipped due to a conflicting lock or a concurrently dropped relation. Enabling this parameter can be helpful in tracking autoanalyze activity. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.

• autoanalyze_max_workers (integer)

  Specifies the maximum number of autoanalyze processes (other than the autoanalyze launcher) that may be running at any one time. The default is three. This parameter can only be set at server start.

• autoanalyze_naptime (integer)

  Specifies the minimum delay between autoanalyze runs on any given database. In each round the daemon examines the database and issues ANALYZE commands as needed for tables in that database. If this value is specified without units, it is taken as seconds. The default is one minute (1min). This parameter can only be set in the postgresql.conf file or on the server command line.

• autoanalyze_base_threshold (integer)

  Specifies the minimum number of inserted, updated or deleted tuples needed to trigger an ANALYZE in any one table. The default is 50 tuples. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.

• autoanalyze_scale_factor (floating point)

  Specifies a fraction of the table size to add to autoanalyze_base_threshold when deciding whether to trigger an ANALYZE. The default is 0.1 (10% of table size). This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.