pg-docs.yml

---
documentation:
  "9.1":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.1/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    checkpoint_segments:
      title: checkpoint_segments
      short_desc: Sets the maximum distance in log segments between automatic WAL
        checkpoints
      details:
      - Maximum number of log file segments between automatic WAL checkpoints (each
        segment is normally 16 megabytes). The default is three segments. Increasing
        this parameter can increase the amount of time needed for crash recovery.
        This parameter can only be set in the postgresql.conf file or on the server
        command line.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-wal.html#GUC-CHECKPOINT-SEGMENTS
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_segments/9.1/
      recomendations_conf: ""
      type: integer
      default_value: "3"
      min_value: "1"
      max_value: "2147483647"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the size of the disk cache
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files. Also, take into account the expected number of concurrent queries
        on different tables, since they will have to share the available space. This
        parameter has no effect on the size of shared memory allocated by PostgreSQL,
        nor does it reserve kernel disk cache; it is used only for estimation purposes.
        The system also does not assume data remains in the disk cache between queries.
        The default is 128 megabytes (128MB).
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.1/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 128MB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - A good starting point for this setting is the number of separate drives comprising
        a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5
        the parity drive should not be counted.) However, if the database is often
        busy with multiple queries issued in concurrent sessions, lower values may
        be sufficient to keep the disk array busy. A value higher than needed to keep
        the disks busy will only result in extra CPU overhead.
      - For more exotic systems, such as memory-based storage or a RAID array that
        is limited by bus bandwidth, the correct value might be the number of I/O
        paths available. Some experimentation may be needed to find the best value.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.1/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.1/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 16 megabytes (16MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to guc-autovacuum-max-workers times this
        memory may be allocated, so be careful not to set the default value too high.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.1/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 16MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory or semaphores than your operating system's default configuration
        allows. See sysvipc for information on how to adjust those parameters, if
        necessary.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.1/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "8388607"
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for a particular tablespace
        by setting the tablespace parameter of the same name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.1/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 32 megabytes (32MB), but might be less if your kernel
        settings will not support it (as determined during initdb). This setting must
        be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in checkpoint_segments, in order to spread out the
        process of writing large quantities of new or changed data over a longer period
        of time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory than your operating system's default configuration allows. See
        sysvipc for information on how to adjust those parameters, if necessary.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.1/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory than your operating system's default configuration allows. See
        sysvipc for information on how to adjust those parameters, if necessary.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.1/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        one megabyte (1MB). Note that for a complex query, several sort or hash operations
        might be running in parallel; each operation will be allowed to use as much
        memory as this value specifies before it starts to write data into temporary
        files. Also, several running sessions could be doing such operations concurrently.
        Therefore, the total memory used could be many times the value of work_mem;
        it is necessary to keep this fact in mind when choosing the value. Sort operations
        are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in
        hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
      url: https://www.postgresql.org/docs/9.1/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.1/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 1MB
      min_value: 64kB
      max_value: 2147483647kB
  "9.2":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.2/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    checkpoint_segments:
      title: checkpoint_segments
      short_desc: Sets the maximum distance in log segments between automatic WAL
        checkpoints
      details:
      - Maximum number of log file segments between automatic WAL checkpoints (each
        segment is normally 16 megabytes). The default is three segments. Increasing
        this parameter can increase the amount of time needed for crash recovery.
        This parameter can only be set in the postgresql.conf file or on the server
        command line.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-wal.html#GUC-CHECKPOINT-SEGMENTS
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_segments/9.2/
      recomendations_conf: ""
      type: integer
      default_value: "3"
      min_value: "1"
      max_value: "2147483647"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the size of the disk cache
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files. Also, take into account the expected number of concurrent queries
        on different tables, since they will have to share the available space. This
        parameter has no effect on the size of shared memory allocated by PostgreSQL,
        nor does it reserve kernel disk cache; it is used only for estimation purposes.
        The system also does not assume data remains in the disk cache between queries.
        The default is 128 megabytes (128MB).
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.2/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 128MB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - A good starting point for this setting is the number of separate drives comprising
        a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5
        the parity drive should not be counted.) However, if the database is often
        busy with multiple queries issued in concurrent sessions, lower values may
        be sufficient to keep the disk array busy. A value higher than needed to keep
        the disks busy will only result in extra CPU overhead.
      - For more exotic systems, such as memory-based storage or a RAID array that
        is limited by bus bandwidth, the correct value might be the number of I/O
        paths available. Some experimentation may be needed to find the best value.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.2/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.2/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 16 megabytes (16MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.2/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 16MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory or semaphores than your operating system's default configuration
        allows. See sysvipc for information on how to adjust those parameters, if
        necessary.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.2/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "8388607"
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four-times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g. solid-state drives, might also be better
        modeled with a lower value for random_page_cost.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.2/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 32 megabytes (32MB), but might be less if your kernel
        settings will not support it (as determined during initdb). This setting must
        be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in checkpoint_segments, in order to spread out the
        process of writing large quantities of new or changed data over a longer period
        of time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory than your operating system's default configuration allows. See
        sysvipc for information on how to adjust those parameters, if necessary.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.2/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      - Increasing this parameter might cause PostgreSQL to request more System V
        shared memory than your operating system's default configuration allows. See
        sysvipc for information on how to adjust those parameters, if necessary.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.2/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        one megabyte (1MB). Note that for a complex query, several sort or hash operations
        might be running in parallel; each operation will be allowed to use as much
        memory as this value specifies before it starts to write data into temporary
        files. Also, several running sessions could be doing such operations concurrently.
        Therefore, the total memory used could be many times the value of work_mem;
        it is necessary to keep this fact in mind when choosing the value. Sort operations
        are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in
        hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
      url: https://www.postgresql.org/docs/9.2/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.2/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 1MB
      min_value: 64kB
      max_value: 2147483647kB
  "9.3":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.3/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    checkpoint_segments:
      title: checkpoint_segments
      short_desc: Sets the maximum distance in log segments between automatic WAL
        checkpoints
      details:
      - Maximum number of log file segments between automatic WAL checkpoints (each
        segment is normally 16 megabytes). The default is three segments. Increasing
        this parameter can increase the amount of time needed for crash recovery.
        This parameter can only be set in the postgresql.conf file or on the server
        command line.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-wal.html#GUC-CHECKPOINT-SEGMENTS
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_segments/9.3/
      recomendations_conf: ""
      type: integer
      default_value: "3"
      min_value: "1"
      max_value: "2147483647"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the size of the data cache
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        128 megabytes (128MB).
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.3/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 128MB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - A good starting point for this setting is the number of separate drives comprising
        a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5
        the parity drive should not be counted.) However, if the database is often
        busy with multiple queries issued in concurrent sessions, lower values may
        be sufficient to keep the disk array busy. A value higher than needed to keep
        the disks busy will only result in extra CPU overhead.
      - For more exotic systems, such as memory-based storage or a RAID array that
        is limited by bus bandwidth, the correct value might be the number of I/O
        paths available. Some experimentation may be needed to find the best value.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.3/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.3/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 16 megabytes (16MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.3/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 16MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.3/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "8388607"
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four-times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g. solid-state drives, might also be better
        modeled with a lower value for random_page_cost.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.3/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in checkpoint_segments, in order to spread out the
        process of writing large quantities of new or changed data over a longer period
        of time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.3/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.3/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        one megabyte (1MB). Note that for a complex query, several sort or hash operations
        might be running in parallel; each operation will be allowed to use as much
        memory as this value specifies before it starts to write data into temporary
        files. Also, several running sessions could be doing such operations concurrently.
        Therefore, the total memory used could be many times the value of work_mem;
        it is necessary to keep this fact in mind when choosing the value. Sort operations
        are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in
        hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
      url: https://www.postgresql.org/docs/9.3/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.3/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 1MB
      min_value: 64kB
      max_value: 2147483647kB
  "9.4":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.4/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    checkpoint_segments:
      title: checkpoint_segments
      short_desc: Sets the maximum distance in log segments between automatic WAL
        checkpoints
      details:
      - Maximum number of log file segments between automatic WAL checkpoints (each
        segment is normally 16 megabytes). The default is three segments. Increasing
        this parameter can increase the amount of time needed for crash recovery.
        This parameter can only be set in the postgresql.conf file or on the server
        command line.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-wal.html#GUC-CHECKPOINT-SEGMENTS
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_segments/9.4/
      recomendations_conf: ""
      type: integer
      default_value: "3"
      min_value: "1"
      max_value: "2147483647"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        4 gigabytes (4GB).
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.4/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - A good starting point for this setting is the number of separate drives comprising
        a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5
        the parity drive should not be counted.) However, if the database is often
        busy with multiple queries issued in concurrent sessions, lower values may
        be sufficient to keep the disk array busy. A value higher than needed to keep
        the disks busy will only result in extra CPU overhead.
      - For more exotic systems, such as memory-based storage or a RAID array that
        is limited by bus bandwidth, the correct value might be the number of I/O
        paths available. Some experimentation may be needed to find the best value.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.4/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.4/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 64 megabytes (64MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting guc-autovacuum-work-mem.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.4/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.4/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "8388607"
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/9.4/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "1"
      max_value: "8388607"
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g. solid-state drives, might also be better
        modeled with a lower value for random_page_cost.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.4/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in checkpoint_segments, in order to spread out the
        process of writing large quantities of new or changed data over a longer period
        of time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.4/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.4/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/9.4/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.4/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "9.5":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.5/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        4 gigabytes (4GB).
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.5/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - A good starting point for this setting is the number of separate drives comprising
        a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5
        the parity drive should not be counted.) However, if the database is often
        busy with multiple queries issued in concurrent sessions, lower values may
        be sufficient to keep the disk array busy. A value higher than needed to keep
        the disks busy will only result in extra CPU overhead.
      - For more exotic systems, such as memory-based storage or a RAID array that
        is limited by bus bandwidth, the correct value might be the number of I/O
        paths available. Some experimentation may be needed to find the best value.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.5/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.5/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 64 megabytes (64MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.5/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.5/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "8388607"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, like
        under heavy load, a failing archive_command, or a high wal_keep_segments setting.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/9.5/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 32MB
      max_value: 34359738352MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/9.5/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "1"
      max_value: "8388607"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. The default is 80 MB. This parameter
        can only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/9.5/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 32MB
      max_value: 34359738352MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.5/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.5/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.5/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/9.5/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.5/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "9.6":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/9.6/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        4 gigabytes (4GB).
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/9.6/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/9.6/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/9.6/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 64 megabytes (64MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/9.6/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/9.6/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        node. Parallel workers are taken from the pool of processes established by
        max_worker_processes. Note that the requested number of workers may not actually
        be available at run time. If this occurs, the plan will run with fewer workers
        than expected, which may be inefficient. Setting this value to 0, which is
        the default, disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/9.6/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "0"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, like
        under heavy load, a failing archive_command, or a high wal_keep_segments setting.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/9.6/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 32MB
      max_value: 34359738352MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/9.6/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. The default is 80 MB. This parameter
        can only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/9.6/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 32MB
      max_value: 34359738352MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/9.6/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even large settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system. Also, on Windows,
        large values for shared_buffers aren't as effective. You may find better results
        keeping the setting relatively low and using the operating system cache more
        instead. The useful range for shared_buffers on Windows systems is generally
        from 64MB to 512MB.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/9.6/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/9.6/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/9.6/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/9.6/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "10":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/10/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/10/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        4 gigabytes (4GB).
      url: https://www.postgresql.org/docs/10/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/10/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/10/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/10/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/10/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 64 megabytes (64MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/10/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/10/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/10/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        queries. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_workers_per_gather. Also, note that a
        setting for this value which is higher than max_worker_processes will have
        no effect, since parallel workers are taken from the pool of worker processes
        established by that setting.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/10/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by guc-max-parallel-workers.
        Note that the requested number of workers may not actually be available at
        run time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/10/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, like
        under heavy load, a failing archive_command, or a high wal_keep_segments setting.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/10/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/10/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting guc-max-parallel-workers
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/10/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. The default is 80 MB. This parameter
        can only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/10/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/10/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/10/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/10/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/10/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/10/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/10/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/10/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/10/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "11":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/11/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/11/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. The default is
        4 gigabytes (4GB).
      url: https://www.postgresql.org/docs/11/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/11/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/11/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/11/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/11/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults
        to 64 megabytes (64MB). Since only one of these operations can be executed
        at a time by a database session, and an installation normally doesn't have
        many of them running concurrently, it's safe to set this value significantly
        larger than work_mem. Larger settings might improve performance for vacuuming
        and for restoring database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/11/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/11/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/11/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/11/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/11/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, like
        under heavy load, a failing archive_command, or a high wal_keep_segments setting.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/11/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/11/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, guc-max-parallel-workers-maintenance,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/11/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. The default is 80 MB. This parameter
        can only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/11/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/11/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/11/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/11/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.)
        However, settings significantly higher than the minimum are usually needed
        for good performance. This parameter can only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/11/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. This parameter can only be set at server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/11/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/11/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Specifies the amount of memory to be used by internal sort operations and
        hash tables before writing to temporary disk files. The value defaults to
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/11/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/11/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "12":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/12/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/12/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. If this value is
        specified without units, it is taken as blocks, that is BLCKSZ bytes, typically
        8kB. The default is 4 gigabytes (4GB). (If BLCKSZ is not 8kB, the default
        value scales proportionally to it.)
      url: https://www.postgresql.org/docs/12/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/12/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/12/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/12/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/12/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value
        is specified without units, it is taken as kilobytes. It defaults to 64 megabytes
        (64MB). Since only one of these operations can be executed at a time by a
        database session, and an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger than work_mem.
        Larger settings might improve performance for vacuuming and for restoring
        database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/12/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/12/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/12/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/12/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/12/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, such
        as heavy load, a failing archive_command, or a high wal_keep_segments setting.
        If this value is specified without units, it is taken as megabytes. The default
        is 1 GB. Increasing this parameter can increase the amount of time needed
        for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/12/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/12/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/12/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. If this value is specified without
        units, it is taken as megabytes. The default is 80 MB. This parameter can
        only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/12/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/12/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/12/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/12/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. However, settings significantly higher than
        the minimum are usually needed for good performance. If this value is specified
        without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB.
        (Non-default values of BLCKSZ change the minimum value.) This parameter can
        only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/12/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. If this value is specified without units, it is taken as WAL blocks,
        that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at
        server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/12/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/12/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Sets the maximum amount of memory to be used by a query operation (such as
        a sort or hash table) before writing to temporary disk files. If this value
        is specified without units, it is taken as kilobytes. The default value is
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will be allowed to
        use as much memory as this value specifies before it starts to write data
        into temporary files. Also, several running sessions could be doing such operations
        concurrently. Therefore, the total memory used could be many times the value
        of work_mem; it is necessary to keep this fact in mind when choosing the value.
        Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables
        are used in hash joins, hash-based aggregation, and hash-based processing
        of IN subqueries.
      url: https://www.postgresql.org/docs/12/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/12/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "13":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.5. This parameter can only be set in
        the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/13/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/13/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.5"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. If this value is
        specified without units, it is taken as blocks, that is BLCKSZ bytes, typically
        8kB. The default is 4 gigabytes (4GB). (If BLCKSZ is not 8kB, the default
        value scales proportionally to it.)
      url: https://www.postgresql.org/docs/13/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/13/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/13/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/13/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/13/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value
        is specified without units, it is taken as kilobytes. It defaults to 64 megabytes
        (64MB). Since only one of these operations can be executed at a time by a
        database session, and an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger than work_mem.
        Larger settings might improve performance for vacuuming and for restoring
        database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/13/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/13/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/13/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/13/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/13/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, such
        as heavy load, a failing archive_command, or a high wal_keep_size setting.
        If this value is specified without units, it is taken as megabytes. The default
        is 1 GB. Increasing this parameter can increase the amount of time needed
        for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/13/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/13/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the master server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/13/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. If this value is specified without
        units, it is taken as megabytes. The default is 80 MB. This parameter can
        only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/13/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/13/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/13/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/13/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. However, settings significantly higher than
        the minimum are usually needed for good performance. If this value is specified
        without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB.
        (Non-default values of BLCKSZ change the minimum value.) This parameter can
        only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/13/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. If this value is specified without units, it is taken as WAL blocks,
        that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at
        server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/13/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/13/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Sets the base maximum amount of memory to be used by a query operation (such
        as a sort or hash table) before writing to temporary disk files. If this value
        is specified without units, it is taken as kilobytes. The default value is
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will generally be
        allowed to use as much memory as this value specifies before it starts to
        write data into temporary files. Also, several running sessions could be doing
        such operations concurrently. Therefore, the total memory used could be many
        times the value of work_mem; it is necessary to keep this fact in mind when
        choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge
        joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based
        processing of IN subqueries.
      - Hash-based operations are generally more sensitive to memory availability
        than equivalent sort-based operations. The memory available for hash tables
        is computed by multiplying work_mem by hash_mem_multiplier. This makes it
        possible for hash-based operations to use an amount of memory that exceeds
        the usual work_mem base amount.
      url: https://www.postgresql.org/docs/13/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/13/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "14":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.9, which spreads the checkpoint across
        almost all of the available interval, providing fairly consistent I/O load
        while also leaving some time for checkpoint completion overhead. Reducing
        this parameter is not recommended because it causes the checkpoint to complete
        faster. This results in a higher rate of I/O during the checkpoint followed
        by a period of less I/O between the checkpoint completion and the next scheduled
        checkpoint. This parameter can only be set in the postgresql.conf file or
        on the server command line.
      url: https://www.postgresql.org/docs/14/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/14/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.9"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. If this value is
        specified without units, it is taken as blocks, that is BLCKSZ bytes, typically
        8kB. The default is 4 gigabytes (4GB). (If BLCKSZ is not 8kB, the default
        value scales proportionally to it.)
      url: https://www.postgresql.org/docs/14/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/14/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/14/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/14/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/14/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value
        is specified without units, it is taken as kilobytes. It defaults to 64 megabytes
        (64MB). Since only one of these operations can be executed at a time by a
        database session, and an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger than work_mem.
        Larger settings might improve performance for vacuuming and for restoring
        database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/14/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/14/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/14/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/14/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/14/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, such
        as heavy load, a failing archive_command, or a high wal_keep_size setting.
        If this value is specified without units, it is taken as megabytes. The default
        is 1 GB. Increasing this parameter can increase the amount of time needed
        for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/14/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/14/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, guc-max-parallel-maintenance-workers,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/14/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. If this value is specified without
        units, it is taken as megabytes. The default is 80 MB. This parameter can
        only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/14/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/14/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/14/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/14/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. However, settings significantly higher than
        the minimum are usually needed for good performance. If this value is specified
        without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB.
        (Non-default values of BLCKSZ change the minimum value.) This parameter can
        only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/14/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 8MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. If this value is specified without units, it is taken as WAL blocks,
        that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at
        server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/14/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/14/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Sets the base maximum amount of memory to be used by a query operation (such
        as a sort or hash table) before writing to temporary disk files. If this value
        is specified without units, it is taken as kilobytes. The default value is
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will generally be
        allowed to use as much memory as this value specifies before it starts to
        write data into temporary files. Also, several running sessions could be doing
        such operations concurrently. Therefore, the total memory used could be many
        times the value of work_mem; it is necessary to keep this fact in mind when
        choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge
        joins. Hash tables are used in hash joins, hash-based aggregation, memoize
        nodes and hash-based processing of IN subqueries.
      - Hash-based operations are generally more sensitive to memory availability
        than equivalent sort-based operations. The memory available for hash tables
        is computed by multiplying work_mem by hash_mem_multiplier. This makes it
        possible for hash-based operations to use an amount of memory that exceeds
        the usual work_mem base amount.
      url: https://www.postgresql.org/docs/14/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/14/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "15":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.9, which spreads the checkpoint across
        almost all of the available interval, providing fairly consistent I/O load
        while also leaving some time for checkpoint completion overhead. Reducing
        this parameter is not recommended because it causes the checkpoint to complete
        faster. This results in a higher rate of I/O during the checkpoint followed
        by a period of less I/O between the checkpoint completion and the next scheduled
        checkpoint. This parameter can only be set in the postgresql.conf file or
        on the server command line.
      url: https://www.postgresql.org/docs/15/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/15/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.9"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. If this value is
        specified without units, it is taken as blocks, that is BLCKSZ bytes, typically
        8kB. The default is 4 gigabytes (4GB). (If BLCKSZ is not 8kB, the default
        value scales proportionally to it.)
      url: https://www.postgresql.org/docs/15/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/15/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/15/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/15/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/15/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value
        is specified without units, it is taken as kilobytes. It defaults to 64 megabytes
        (64MB). Since only one of these operations can be executed at a time by a
        database session, and an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger than work_mem.
        Larger settings might improve performance for vacuuming and for restoring
        database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/15/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/15/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/15/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/15/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/15/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, such
        as heavy load, a failing archive_command or archive_library, or a high wal_keep_size
        setting. If this value is specified without units, it is taken as megabytes.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/15/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/15/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/15/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. If this value is specified without
        units, it is taken as megabytes. The default is 80 MB. This parameter can
        only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/15/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/15/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/15/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/15/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. However, settings significantly higher than
        the minimum are usually needed for good performance. If this value is specified
        without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB.
        (Non-default values of BLCKSZ change the minimum value.) This parameter can
        only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/15/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 128MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. If this value is specified without units, it is taken as WAL blocks,
        that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at
        server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/15/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/15/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Sets the base maximum amount of memory to be used by a query operation (such
        as a sort or hash table) before writing to temporary disk files. If this value
        is specified without units, it is taken as kilobytes. The default value is
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will generally be
        allowed to use as much memory as this value specifies before it starts to
        write data into temporary files. Also, several running sessions could be doing
        such operations concurrently. Therefore, the total memory used could be many
        times the value of work_mem; it is necessary to keep this fact in mind when
        choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge
        joins. Hash tables are used in hash joins, hash-based aggregation, memoize
        nodes and hash-based processing of IN subqueries.
      - Hash-based operations are generally more sensitive to memory availability
        than equivalent sort-based operations. The memory available for hash tables
        is computed by multiplying work_mem by hash_mem_multiplier. This makes it
        possible for hash-based operations to use an amount of memory that exceeds
        the usual work_mem base amount.
      url: https://www.postgresql.org/docs/15/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/15/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB
  "16":
    checkpoint_completion_target:
      title: checkpoint_completion_target
      short_desc: Time spent flushing dirty buffers during checkpoint, as fraction
        of checkpoint interval
      details:
      - Specifies the target of checkpoint completion, as a fraction of total time
        between checkpoints. The default is 0.9, which spreads the checkpoint across
        almost all of the available interval, providing fairly consistent I/O load
        while also leaving some time for checkpoint completion overhead. Reducing
        this parameter is not recommended because it causes the checkpoint to complete
        faster. This results in a higher rate of I/O during the checkpoint followed
        by a period of less I/O between the checkpoint completion and the next scheduled
        checkpoint. This parameter can only be set in the postgresql.conf file or
        on the server command line.
      url: https://www.postgresql.org/docs/16/static/runtime-config-wal.html#GUC-CHECKPOINT-COMPLETION-TARGET
      conf_url: https://postgresqlco.nf/en/doc/param/checkpoint_completion_target/16/
      recomendations_conf: Defines the fraction of one checkpoint_interval over which
        to spread checkpoints. The default value works for most users.
      type: floating point
      default_value: "0.9"
      min_value: "0"
      max_value: "1"
    effective_cache_size:
      title: effective_cache_size
      short_desc: Sets the planner's assumption about the total size of the data caches
      details:
      - Sets the planner's assumption about the effective size of the disk cache that
        is available to a single query. This is factored into estimates of the cost
        of using an index; a higher value makes it more likely index scans will be
        used, a lower value makes it more likely sequential scans will be used. When
        setting this parameter you should consider both PostgreSQL's shared buffers
        and the portion of the kernel's disk cache that will be used for PostgreSQL
        data files, though some data might exist in both places. Also, take into account
        the expected number of concurrent queries on different tables, since they
        will have to share the available space. This parameter has no effect on the
        size of shared memory allocated by PostgreSQL, nor does it reserve kernel
        disk cache; it is used only for estimation purposes. The system also does
        not assume data remains in the disk cache between queries. If this value is
        specified without units, it is taken as blocks, that is BLCKSZ bytes, typically
        8kB. The default is 4 gigabytes (4GB). (If BLCKSZ is not 8kB, the default
        value scales proportionally to it.)
      url: https://www.postgresql.org/docs/16/static/runtime-config-query.html#GUC-EFFECTIVE-CACHE-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/effective_cache_size/16/
      recomendations_conf: Tells the PostgreSQL query planner how much RAM is estimated
        to be available for caching data, in both shared_buffers and in the filesystem
        cache. This setting just helps the planner make good cost estimates; it does
        not actually allocate the memory.
      type: integer
      default_value: 4GB
      min_value: 8kB
      max_value: 17179869176kB
    effective_io_concurrency:
      title: effective_io_concurrency
      short_desc: Number of simultaneous requests that can be handled efficiently
        by the disk subsystem
      details:
      - Sets the number of concurrent disk I/O operations that PostgreSQL expects
        can be executed simultaneously. Raising this value will increase the number
        of I/O operations that any individual PostgreSQL session attempts to initiate
        in parallel. The allowed range is 1 to 1000, or zero to disable issuance of
        asynchronous I/O requests. Currently, this setting only affects bitmap heap
        scans.
      - For magnetic drives, a good starting point for this setting is the number
        of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used
        for the database. (For RAID 5 the parity drive should not be counted.) However,
        if the database is often busy with multiple queries issued in concurrent sessions,
        lower values may be sufficient to keep the disk array busy. A value higher
        than needed to keep the disks busy will only result in extra CPU overhead.
        SSDs and other memory-based storage can often process many concurrent requests,
        so the best value might be in the hundreds.
      - Asynchronous I/O depends on an effective posix_fadvise function, which some
        operating systems lack. If the function is not present then setting this parameter
        to anything but zero will result in an error. On some operating systems (e.g.,
        Solaris), the function is present but does not actually do anything.
      - The default is 1 on supported systems, otherwise 0. This value can be overridden
        for tables in a particular tablespace by setting the tablespace parameter
        of the same name (see sql-altertablespace).
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-EFFECTIVE-IO-CONCURRENCY
      conf_url: https://postgresqlco.nf/en/doc/param/effective_io_concurrency/16/
      recomendations_conf: Set to the number of disks in your RAID array or number
        of I/O channels.  Available only for platforms with posix_fadvise support
        (i.e. Linux).  Currently only affects the execution of parallel bitmapscan,
        but might affect other I/O operations in future versions.
      type: integer
      default_value: "1"
      min_value: "0"
      max_value: "1000"
    listen_addresses:
      title: listen_addresses
      short_desc: Sets the host name or IP address(es) to listen to
      details:
      - 'Specifies the TCP/IP address(es) on which the server is to listen for connections
        from client applications. The value takes the form of a comma-separated list
        of host names and/or numeric IP addresses. The special entry * corresponds
        to all available IP interfaces. The entry 0.0.0.0 allows listening for all
        IPv4 addresses and :: allows listening for all IPv6 addresses. If the list
        is empty, the server does not listen on any IP interface at all, in which
        case only Unix-domain sockets can be used to connect to it. The default value
        is localhost, which allows only local TCP/IP loopback connections to be made.
        While client authentication (client-authentication) allows fine-grained control
        over who can access the server, listen_addresses controls which interfaces
        accept connection attempts, which can help prevent repeated malicious connection
        requests on insecure network interfaces. This parameter can only be set at
        server start.'
      url: https://www.postgresql.org/docs/16/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
      conf_url: https://postgresqlco.nf/en/doc/param/listen_addresses/16/
      recomendations_conf: Set your listen_address as restrictively as possible; '*'
        should only be used for development machines
      type: string
      default_value: localhost
      min_value: postmaster
      max_value: "true"
    maintenance_work_mem:
      title: maintenance_work_mem
      short_desc: Sets the maximum memory to be used for maintenance operations
      details:
      - Specifies the maximum amount of memory to be used by maintenance operations,
        such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value
        is specified without units, it is taken as kilobytes. It defaults to 64 megabytes
        (64MB). Since only one of these operations can be executed at a time by a
        database session, and an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger than work_mem.
        Larger settings might improve performance for vacuuming and for restoring
        database dumps.
      - Note that when autovacuum runs, up to autovacuum_max_workers times this memory
        may be allocated, so be careful not to set the default value too high. It
        may be useful to control for this by separately setting autovacuum_work_mem.
      - Note that for the collection of dead tuple identifiers, VACUUM is only able
        to utilize up to a maximum of 1GB of memory.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/maintenance_work_mem/16/
      recomendations_conf: Sets the limit for the amount that autovacuum, manual vacuum,
        bulk index build and other maintenance routines are permitted to use.  Setting
        it to a moderately high value will increase the efficiency of vacuum and other
        operations.  Applications which perform large ETL operations may need to allocate
        up to 1/4 of RAM to support large bulk vacuums.  Note that each autovacuum
        worker may use this much, so if using multiple autovacuum workers you may
        want to decrease this value so that they can't claim over 1/8 or 1/4 of available
        RAM.
      type: integer
      default_value: 64MB
      min_value: 1MB
      max_value: 2147483647kB
    max_connections:
      title: max_connections
      short_desc: Sets the maximum number of concurrent connections
      details:
      - Determines the maximum number of concurrent connections to the database server.
        The default is typically 100 connections, but might be less if your kernel
        settings will not support it (as determined during initdb). This parameter
        can only be set at server start.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      url: https://www.postgresql.org/docs/16/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
      conf_url: https://postgresqlco.nf/en/doc/param/max_connections/16/
      recomendations_conf: Should be set to the maximum number of connections which
        you expect to need at peak load.  Note that each connection uses shared_buffer
        memory, as well as additional non-shared memory, so be careful not to run
        the system out of memory.  In general, if you need more than 200 connections,
        you should probably be making more use of connection pooling.
      type: integer
      default_value: "100"
      min_value: "1"
      max_value: "262143"
    max_parallel_workers:
      title: max_parallel_workers
      short_desc: Sets the maximum number of parallel workers that can be active at
        one time
      details:
      - Sets the maximum number of workers that the system can support for parallel
        operations. The default value is 8. When increasing or decreasing this value,
        consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather.
        Also, note that a setting for this value which is higher than max_worker_processes
        will have no effect, since parallel workers are taken from the pool of worker
        processes established by that setting.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers/16/
      recomendations_conf: …  if you think you can benefit from parallel query, and
        even cores/1 for DW systems.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "1024"
    max_parallel_workers_per_gather:
      title: max_parallel_workers_per_gather
      short_desc: Sets the maximum number of parallel processes per executor node
      details:
      - Sets the maximum number of workers that can be started by a single Gather
        or Gather Merge node. Parallel workers are taken from the pool of processes
        established by max_worker_processes, limited by max_parallel_workers. Note
        that the requested number of workers may not actually be available at run
        time. If this occurs, the plan will run with fewer workers than expected,
        which may be inefficient. The default value is 2. Setting this value to 0
        disables parallel query execution.
      - Note that parallel queries may consume very substantially more resources than
        non-parallel queries, because each worker process is a completely separate
        process which has roughly the same impact on the system as an additional user
        session. This should be taken into account when choosing a value for this
        setting, as well as when configuring other settings that control resource
        utilization, such as work_mem. Resource limits such as work_mem are applied
        individually to each worker, which means the total utilization may be much
        higher across all processes than it would normally be for any single process.
        For example, a parallel query using 4 workers may use up to 5 times as much
        CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers
        at all.
      - For more information on parallel query, see parallel-query.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS-PER-GATHER
      conf_url: https://postgresqlco.nf/en/doc/param/max_parallel_workers_per_gather/16/
      recomendations_conf: Increase if you plan to use parallel query to 4 or 8, depending
        on cores/concurrent sessions.
      type: integer
      default_value: "2"
      min_value: "0"
      max_value: "1024"
    max_wal_size:
      title: max_wal_size
      short_desc: Sets the WAL size that triggers a checkpoint
      details:
      - Maximum size to let the WAL grow during automatic checkpoints. This is a soft
        limit; WAL size can exceed max_wal_size under special circumstances, such
        as heavy load, a failing archive_command or archive_library, or a high wal_keep_size
        setting. If this value is specified without units, it is taken as megabytes.
        The default is 1 GB. Increasing this parameter can increase the amount of
        time needed for crash recovery. This parameter can only be set in the postgresql.conf
        file or on the server command line.
      url: https://www.postgresql.org/docs/16/static/runtime-config-wal.html#GUC-MAX-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/max_wal_size/16/
      recomendations_conf: … except for databases that write more than 1GB/hour of
        data, in which case increase the size of the log so that it's at least an
        hour worth of logs
      type: integer
      default_value: 1GB
      min_value: 2MB
      max_value: 2147483647MB
    max_worker_processes:
      title: max_worker_processes
      short_desc: Maximum number of concurrent worker processes
      details:
      - Sets the maximum number of background processes that the system can support.
        This parameter can only be set at server start. The default is 8.
      - When running a standby server, you must set this parameter to the same or
        higher value than on the primary server. Otherwise, queries will not be allowed
        in the standby server.
      - When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers,
        and max_parallel_workers_per_gather.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES
      conf_url: https://postgresqlco.nf/en/doc/param/max_worker_processes/16/
      recomendations_conf: Increase to max_parallel_workers + other workers, such
        as workers for logical replication and custom background workers.  Not more
        than your number of cores, though.
      type: integer
      default_value: "8"
      min_value: "0"
      max_value: "262143"
    min_wal_size:
      title: min_wal_size
      short_desc: Sets the minimum size to shrink the WAL to
      details:
      - As long as WAL disk usage stays below this setting, old WAL files are always
        recycled for future use at a checkpoint, rather than removed. This can be
        used to ensure that enough WAL space is reserved to handle spikes in WAL usage,
        for example when running large batch jobs. If this value is specified without
        units, it is taken as megabytes. The default is 80 MB. This parameter can
        only be set in the postgresql.conf file or on the server command line.
      url: https://www.postgresql.org/docs/16/static/runtime-config-wal.html#GUC-MIN-WAL-SIZE
      conf_url: https://postgresqlco.nf/en/doc/param/min_wal_size/16/
      recomendations_conf: ""
      type: integer
      default_value: 80MB
      min_value: 2MB
      max_value: 2147483647MB
    random_page_cost:
      title: random_page_cost
      short_desc: Sets the planner's estimate of the cost of a nonsequentially fetched
        disk page
      details:
      - Sets the planner's estimate of the cost of a non-sequentially-fetched disk
        page. The default is 4.0. This value can be overridden for tables and indexes
        in a particular tablespace by setting the tablespace parameter of the same
        name (see sql-altertablespace).
      - Reducing this value relative to seq_page_cost will cause the system to prefer
        index scans; raising it will make index scans look relatively more expensive.
        You can raise or lower both values together to change the importance of disk
        I/O costs relative to CPU costs, which are described by the following parameters.
      - Random access to mechanical disk storage is normally much more expensive than
        four times sequential access. However, a lower default is used (4.0) because
        the majority of random accesses to disk, such as indexed reads, are assumed
        to be in cache. The default value can be thought of as modeling random access
        as 40 times slower than sequential, while expecting 90% of random reads to
        be cached.
      - If you believe a 90% cache rate is an incorrect assumption for your workload,
        you can increase random_page_cost to better reflect the true cost of random
        storage reads. Correspondingly, if your data is likely to be completely in
        cache, such as when the database is smaller than the total server memory,
        decreasing random_page_cost can be appropriate. Storage that has a low random
        read cost relative to sequential, e.g., solid-state drives, might also be
        better modeled with a lower value for random_page_cost, e.g., 1.1.
      url: https://www.postgresql.org/docs/16/static/runtime-config-query.html#GUC-RANDOM-PAGE-COST
      conf_url: https://postgresqlco.nf/en/doc/param/random_page_cost/16/
      recomendations_conf: Sets the ratio of seek to scan time for your database storage.  Should
        not be altered unless you're using special storage (SSDs, high end SANs, etc.)
        where seek/scan ratios are actually different.  If you need the database to
        favor indexes more, tune effective_cache_size and some of the cpu_* costs
        instead.
      type: floating point
      default_value: "4"
      min_value: "0"
      max_value: "1.79769e+308"
    shared_buffers:
      title: shared_buffers
      short_desc: Sets the number of shared memory buffers used by the server
      details:
      - Sets the amount of memory the database server uses for shared memory buffers.
        The default is typically 128 megabytes (128MB), but might be less if your
        kernel settings will not support it (as determined during initdb). This setting
        must be at least 128 kilobytes. However, settings significantly higher than
        the minimum are usually needed for good performance. If this value is specified
        without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB.
        (Non-default values of BLCKSZ change the minimum value.) This parameter can
        only be set at server start.
      - If you have a dedicated database server with 1GB or more of RAM, a reasonable
        starting value for shared_buffers is 25% of the memory in your system. There
        are some workloads where even larger settings for shared_buffers are effective,
        but because PostgreSQL also relies on the operating system cache, it is unlikely
        that an allocation of more than 40% of RAM to shared_buffers will work better
        than a smaller amount. Larger settings for shared_buffers usually require
        a corresponding increase in max_wal_size, in order to spread out the process
        of writing large quantities of new or changed data over a longer period of
        time.
      - On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate,
        so as to leave adequate space for the operating system.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-SHARED-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/shared_buffers/16/
      recomendations_conf: 'A memory quantity defining PostgreSQL''s "dedicated" RAM,
        which is used for connection control, active operations, and more.  However,
        since PostgreSQL also needs free RAM for file system buffers, sorts and maintenance
        operations, it is not advisable to set shared_buffers to a majority of RAM.   Note
        that increasing shared_buffers often requires you to increase some  system
        kernel parameters, most notably SHMMAX and SHMALL.  See  Operating System
        Environment: Managing Kernel Resources in the PostgreSQL documentation for
        more details.  Also note that shared_buffers over 2GB is  only supported on
        64-bit systems.'
      type: integer
      default_value: 128MB
      min_value: 128kB
      max_value: 8589934584kB
    wal_buffers:
      title: wal_buffers
      short_desc: Sets the number of disk-page buffers in shared memory for WAL
      details:
      - The amount of shared memory used for WAL data that has not yet been written
        to disk. The default setting of -1 selects a size equal to 1/32nd (about 3%)
        of shared_buffers, but not less than 64kB nor more than the size of one WAL
        segment, typically 16MB. This value can be set manually if the automatic choice
        is too large or too small, but any positive value less than 32kB will be treated
        as 32kB. If this value is specified without units, it is taken as WAL blocks,
        that is XLOG_BLCKSZ bytes, typically 8kB. This parameter can only be set at
        server start.
      - The contents of the WAL buffers are written out to disk at every transaction
        commit, so extremely large values are unlikely to provide a significant benefit.
        However, setting this value to at least a few megabytes can improve write
        performance on a busy server where many clients are committing at once. The
        auto-tuning selected by the default setting of -1 should give reasonable results
        in most cases.
      url: https://www.postgresql.org/docs/16/static/runtime-config-wal.html#GUC-WAL-BUFFERS
      conf_url: https://postgresqlco.nf/en/doc/param/wal_buffers/16/
      recomendations_conf: On very busy, high-core machines it can be useful to raise
        this to as much as 128MB.
      type: integer
      default_value: "-1"
      min_value: "-1"
      max_value: 2097144kB
    work_mem:
      title: work_mem
      short_desc: Sets the maximum memory to be used for query workspaces
      details:
      - Sets the base maximum amount of memory to be used by a query operation (such
        as a sort or hash table) before writing to temporary disk files. If this value
        is specified without units, it is taken as kilobytes. The default value is
        four megabytes (4MB). Note that for a complex query, several sort or hash
        operations might be running in parallel; each operation will generally be
        allowed to use as much memory as this value specifies before it starts to
        write data into temporary files. Also, several running sessions could be doing
        such operations concurrently. Therefore, the total memory used could be many
        times the value of work_mem; it is necessary to keep this fact in mind when
        choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge
        joins. Hash tables are used in hash joins, hash-based aggregation, memoize
        nodes and hash-based processing of IN subqueries.
      - Hash-based operations are generally more sensitive to memory availability
        than equivalent sort-based operations. The memory available for hash tables
        is computed by multiplying work_mem by hash_mem_multiplier. This makes it
        possible for hash-based operations to use an amount of memory that exceeds
        the usual work_mem base amount.
      url: https://www.postgresql.org/docs/16/static/runtime-config-resource.html#GUC-WORK-MEM
      conf_url: https://postgresqlco.nf/en/doc/param/work_mem/16/
      recomendations_conf: Sets the limit for the amount of non-shared RAM available
        for each query operation, including sorts and hashes.  This limit acts as
        a primitive resource control, preventing the server from going into swap due
        to overallocation.  Note that this is non-shared RAM per operation, which
        means large complex queries can use multple times this amount.  Also, work_mem
        is allocated by powers of two, so round to the nearest binary step.  The second
        formula is for reporting and DW servers which run a lot of complex queries.
      type: integer
      default_value: 4MB
      min_value: 64kB
      max_value: 2147483647kB