데이터베이스 서버가 공유 메모리 버퍼용으로 사용하는 메모리 양을 설정한다. 기본값은 일반적으로 128메가바이트(128MB)이지만 커널 설정에서 지원하지 않는 경우 여기에 미치지 못할 수 있다(initdb 중에 결정됨). 이 설정은 최소 128킬로바이트여야 한다. 단, 최소값보다 훨씬 큰 설정은 일반적으로 우수한 성능이 필요할 때 사용된다. 단위를 지정하지 않으면 블록수로 간주하며, 그 단위는 BLCKSZ 바이트이다. 통상 8kB. (BLCKSZ 값이 바뀌면 최소값도 바뀐다.) 이 매개 변수값은 서버를 시작할 때만 지정할 수 있다.

RAM이 1GB 이상인 전용 데이터베이스 서버를 사용하는 경우 shared_buffers의 적절한 시작 값은 시스템 메모리의 25%이다. 일부 작업 부하는 shared_buffers에 대한 설정이 클수록 효과적이지만, PostgreSQL 역시 운영 체제 캐시에 의존적이므로 시스템 효율을 위해 40% 이상의 RAM을 shared_buffers에 할당하는 것은 좋지 않다. 장시간에 걸쳐 대량의 새 데이터 또는 변경된 데이터 쓰기 프로세스를 실행하기 위해 shared_buffers를 더 크게 설정하면 checkpoint_segments에서도 그에 맞게 설정을 증가시켜야 한다.

시스템 RAM이 1GB 미만인 경우에는 운영 체제를 위한 적정 공간이 필요하므로 RAM 비율을 더 작게 하는 것이 맞다.

Controls whether huge pages are requested for the main shared memory area. Valid values are try (the default), on, and off. With huge_pages set to try, the server will try to request huge pages, but fall back to the default if that fails. With on, failure to request huge pages will prevent the server from starting up. With off, huge pages will not be requested.

현재, 이 설정은 리눅스와 윈도우즈에서만 사용할 수 있다. 다른 시스템에서 try로 설정하면, 그 설정은 무시한다.

huge pages 페이지의 사용은 결과적으로 메모리 관리에 더 작은 페이지 테이블과 더 짧은 CPU 시간으로 이어지고 성능도 증가한다. 리눅스 huge page에 대한 자세한 내용은 18.4.5절을 참조 바란다.

Huge pages are known as large pages on Windows. To use them, you need to assign the user right Lock Pages in Memory to the Windows user account that runs PostgreSQL. You can use Windows Group Policy tool (gpedit.msc) to assign the user right Lock Pages in Memory. To start the database server on the command prompt as a standalone process, not as a Windows service, the command prompt must be run as an administrator or User Access Control (UAC) must be disabled. When the UAC is enabled, the normal command prompt revokes the user right Lock Pages in Memory when started.

Note that this setting only affects the main shared memory area. Operating systems such as Linux, FreeBSD, and Illumos can also use huge pages (also known as “super” pages or “large” pages) automatically for normal memory allocation, without an explicit request from PostgreSQL. On Linux, this is called “transparent huge pages” (THP). That feature has been known to cause performance degradation with PostgreSQL for some users on some Linux versions, so its use is currently discouraged (unlike explicit use of huge_pages).

데이터베이스 각 세션이 사용하는 임시 버퍼의 최대 수를 설정한다. 임시 테이블에 액세스하는 용도로만 사용되는 세션 로컬 버퍼가 있다. 단위를 지정하지 않으면 블록수로 간주한다. 블록 크기는 BLCKSZ 바이트이며, 통상 8kB다. 기본값은 8메가바이트(8MB)이다. (BLCKSZ 값이 8kB가 아니면, 기본값도 그 값에 비례한다.) 설정은 개별 세션 내에서 변경할 수 있지만 세션 내 임시 테이블을 처음 사용하기 전에만 가능하다. 이후에 값을 변경하면 해당 세션에서 효과가 없다.

세션은 temp_buffers에 설정된 한계까지, 필요한 임시 버퍼를 할당한다. 실제로는 임시 버퍼가 많이 필요 없는 세션에서 큰 값을 설정하는 데 드는 비용은 버퍼 디스크립터 또는 temp_buffers 증가별로 약 64바이트에 불과하다. 그러나 버퍼가 실제로 사용되는 경우에는 8192바이트가 추가로 필요하다(또는 일반적으로 BLCKSZ 바이트).

동시에 “준비된” 상태일 수 있는 트랜잭션의 최대 수를 설정한다(PREPARE TRANSACTION 참조).

준비된 트랜잭션을 사용할 계획이 없으면 이 매개 변수는 0으로 설정하여 준비된 트랜잭션을 생성하는 실수를 방지해야 한다. 준비된 트랜잭션을 사용하는 경우 max_prepared_transactions가 최소한 max_connections 이상이 되도록 설정하여 세션은 준비된 트랜잭션을 보류시킬 수 있다.

대기 서버 실행 중에 이 매개 변수를 마스터 서버 값보다 크거나 같게 설정해야 한다. 그렇지 않으면 대기 서버에서 쿼리가 허용되지 않는다.

임시 디스크 파일을 쓰기 전에 내부 정렬 명령 및 해시 테이블에서 사용되는 기본 최대 메모리 양을 지정한다. 단위를 지정하지 않으면 kB로 간주한다. 기본값은 4메가바이트이다(4MB). 복잡한 쿼리의 경우 몇 가지 정렬 또는 해시 명령이 병렬로 실행될 수 있다. 각각의 명령은 데이터를 임시 파일에 쓰기 전에 이 값에 지정된 크기만큼 메모리를 사용할 것이다. 또는 실행 중인 여러 세션은 해당 명령을 동시에 실행할 수도 있다. 따라서 사용될 총 메모리는 work_mem의 몇배가 될 것이다. 값을 선택할 때 이러한 사실을 유념할 필요가 있다. 정렬 명령은 ORDER BY, DISTINCT 및 머지 조인에 사용된다. 해시 테이블은 해시 조인, 해시 기반 집계(aggregation), IN 서브쿼리의 해시 기반 처리에 사용된다.

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.

Used to compute the maximum amount of memory that hash-based operations can use. The final limit is determined by multiplying work_mem by hash_mem_multiplier. The default value is 1.0, which makes hash-based operations subject to the same simple work_mem maximum as sort-based operations.

Consider increasing hash_mem_multiplier in environments where spilling by query operations is a regular occurrence, especially when simply increasing work_mem results in memory pressure (memory pressure typically takes the form of intermittent out of memory errors). A setting of 1.5 or 2.0 may be effective with mixed workloads. Higher settings in the range of 2.0 - 8.0 or more may be effective in environments where work_mem has already been increased to 40MB or more.

VACUUM, CREATE INDEX 및 ALTER TABLE ADD FOREIGN KEY 같은 유지보수 명령에서 사용되는 최대 메모리 양을 지정한다. 단위를 지정하지 않으면 kB로 간주한다. 기본값은 64메가바이트이다(64MB). 이러한 명령은 데이터베이스 세션에서 한 번에 하나만 실행할 수 있으며, 정상 설치에는 동시 실행되는 명령이 여러 개 있을 수 없다. 이 값은 work_mem보다 훨씬 큰 값으로 설정하는 것이 안전하다. 설정값이 큰 경우에는 vacuuming 및 데이터베이스 덤프 복구 성능이 개선될 수 있다.

autovacuum 실행 시 이 메모리에서 autovacuum_max_workers의 배수로 할당할 수 있으므로 기본값을 너무 높게 설정하지 않도록 해야 한다. autovacuum_work_mem을 별도 설정하여 이것을 관리하는 것이 유용할 수 있다.

각각의 autovacuum worker 프로세스에서 사용되는 최대 메모리 양을 지정한다. 단위를 지정하지 않으면, kB로 간주한다. 기본값은 maintenance_work_mem 값을 대신 사용해야 함으로 나타내는 -1이다. 다른 컨텍스트에서 실행하는 경우 이 설정은 VACUUM의 동작에 효과가 없다.

Specifies the maximum amount of memory to be used by logical decoding, before some of the decoded changes are written to local disk. This limits the amount of memory used by logical streaming replication connections. It defaults to 64 megabytes (64MB). Since each replication connection only uses a single buffer of this size, and an installation normally doesn't have many such connections concurrently (as limited by max_wal_senders), it's safe to set this value significantly higher than work_mem, reducing the amount of decoded changes written to disk.

서버 실행 스택의 최대 안전 깊이를 지정한다. 이 매개 변수의 이상적인 설정은 커널이 강제로 지정한 안전 마진(safety margin)에서 약간 부족한 실제 스택 크기 제한이다(ulimit -s에 의해 설정된 대로, 또는 로컬과 동등). 모든 루틴이 아니라 잠재적 재귀 루틴 중 중요한 것만 스택 깊이가 검사되기 때문에, 안전 마진(safety margin)이 필요하다. 단위를 지정하지 않으면, kB로 간주한다. 기본 설정은, 기본적으로 적게 잡고 충돌 가능성이 낮은 2메가바이트이다(2MB). 그러나, 설정값이 너무 작으면 복합 함수의 실행이 어려울 수 있다. 슈퍼유저만 이 설정을 변경할 수 있다.

실제 커널 제한보다 max_stack_depth를 큰 값으로 설정하면 런어웨이 재귀 함수가 개별 백엔드 프로세스와 충돌할 수 있다. PostgreSQL이 커널 제한을 결정할 수 있는 플랫폼에서 서버는 이 변수가 불안정한 값으로 설정되는 것을 허용하지 않는다. 그러나 모든 플랫폼이 정보를 제공하지는 않으므로 값 선택 시 신중을 기해야 한다.

Specifies the shared memory implementation that the server should use for the main shared memory region that holds PostgreSQL's shared buffers and other shared data. Possible values are mmap (for anonymous shared memory allocated using mmap), sysv (for System V shared memory allocated via shmget) and windows (for Windows shared memory). Not all values are supported on all platforms; the first supported option is the default for that platform. The use of the sysv option, which is not the default on any platform, is generally discouraged because it typically requires non-default kernel settings to allow for large allocations (see 18.4.1절).

서버가 사용해야 하는 동적 공유 메모리 구현을 지정한다. 가능한 값은 posix(shm_open을 사용하여 할당된 POSIX 공유 메모리의 경우), sysv(shmget을 통해 할당된 System V 공유 메모리의 경우), windows(Windows 공유 메모리의 경우), mmap(데이터 디렉터리에 저장된 메모리 맵 파일을 사용하는 공유 메모리 시뮬레이션). 몇몇 플랫폼에서는 일부 값이 지원되지 않는다. 첫 번째 지원 옵션은 해당 플랫폼의 기본값이다. 플랫폼에서 기본값이 아닌 mmap 옵션의 사용은 일반적으로 권장되지 않는다. 이유는 운영 체제가 수정된 페이지를 디스크에 반복해서 다시 쓰면서 시스템 I/O 로드가 늘어나기 때문이다. 그러나, pg_dynshmem 디렉터리를 RAM 디스크에 저장하거나 다른 공유 메모리 기능을 사용할 수 없는 경우에는 디버깅용으로 유용하다.

정렬 및 해시 임시 파일 같은 임시 파일 또는 보류된 커서용 저장소 파일에 프로세스가 사용할 수 있는 디스크 공간의 최대 크기를 지정한다. 이 제한을 초과하는 트랜잭션은 취소된다. 단위를 지정하지 않으면, kB로 간주한다. -1(기본값)은 무제한을 의미한다. 슈퍼유저만 이 설정을 변경할 수 있다.

이 설정은 주어진 PostgreSQL 프로세스에 의해 동시에 사용되는 모든 임시 파일의 총 공간을 제한한다. 쿼리 실행 시 은밀하게 사용되는 임시 파일과 달리, 명시적 임시 테이블용으로 사용되는 디스크 공간은 이 제한에 합산되지 않는다는 점에 유의해야 한다.

서버 하위 프로세스별로 허용된 동시 개방 파일의 최대 수를 설정한다. 기본값은 1000개 파일이다. 커널이 프로세스별 안전 한계를 강제하는 경우 이 설정은 신경 쓸 필요가 없다. 그러나 일부 플랫폼(특히, 대부분의 BSD 시스템)에서, 여러 개의 프로세스가 모두 다수의 파일을 열려고 시도하면 커널은 시스템이 실제로 지원하는 것보다 훨씬 더 많은 파일을 개별 프로세스가 여는 것을 허용한다. “Too many open files” 실패가 나타난 경우 이 설정을 줄여야 한다. 이 매개 변수는 서버 시작 시에만 설정 가능하다.

비용 제한을 초과한 경우 프로세스가 슬립하는 시간. 단위를 지정하지 않으면 밀리세컨드로 간주한다. 기본값은, 비용 기반 vacuum 지연 기능을 사용하지 않는 0이다. 양수 값은 비용 기반 vacuuming을 사용하는 것으로 설정된다.

비용 기반 vacuuming을 사용하는 경우 vacuum_cost_delay는 일반적으로 매우 작으며, 보통 1ms 보다 적은 값을 사용한다. vacuum_cost_delay 값으로 소수값을 사용할 수 있지만, 옛날 OS인 경우는 이 계산이 정확하지 않을 수 있다. 이런 OS에서는 이 값을 1ms 이상 지정할 수 있으며, 이 때는 다른 vacuum 비용 관련 설정들을 바꿀 필요가 있다. 그럼에도 불구하고, vacuum_cost_delay 값은 최대한 작은 값을 사용해야한다. 큰 값은 도움이 되지 않는다.

공유 버퍼 캐시에 있는 버퍼 vacuuming의 예상 비용. 이것은 버퍼 풀을 잠그고, 공유 해시 테이블을 조회하고 페이지 내용을 스캔 하는 비용을 나타낸다. 기본값은 1이다.

디스크에서 읽어온 버퍼를 vacuuming하는 데 드는 예상 비용. 이것은 버퍼 풀을 잠그고, 공유 해시 테이블을 조회하고, 디스크에어 원하는 블록을 읽고, 내용을 스캔하는 비용을 나타낸다. 기본값은 10이다.

이전에 클린한 블록을 vacuum이 수정하는 경우 예상 비용. 이것은 dirty 블록을 디스크에 다시 쓰는 데 필요한 추가 I/O를 나타낸다. 기본값은 20이다.

vacuuming 프로세스를 슬립 시키는 누적 비용. 기본값은 200이다.

background writer의 작업 라운드 사이의 지연을 지정한다. 각 라운드에서 writer는 몇 개의 dirty 버퍼(다음 매개 변수로 조절 가능)에 대해 쓰기를 실행한다. 그런 다음, bgwriter_delay 시간 동안 슬립한 다음, 반복한다. 버퍼 풀에 dirty 버퍼가 없으면, bgwriter_delay와 무관하게 장기 슬립으로 들어간다. 단위를 지정하지 않으면 ms로 간주한다. 기본값은 200밀리초이다(200ms). 다수의 시스템에서 슬립 지연의 효율적인 설정은 10밀리초이다. bgwriter_delay를 10의 배수가 아닌 다른 값으로 설정하면 10의 배수로 값을 올림하여 설정한 것과 결과가 동일하다. 이 매개 변수는 postgresql.conf 파일 또는 서버 명령행 옵션값으로만 설정 가능하다.

각 라운드에서 이것보다 큰 버퍼 수는 백그라운드 writer에 의해 쓰기가 되지 않는다. 이것을 0으로 설정하면 백그라운드 쓰기가 사용되지 않는다. (별도의 전용 보조 프로세스에 의해 관리되는 해당 checkpoints는 영향을 받지 않는다.) 기본값은 100개 버퍼이다. 이 매개 변수는 postgresql.conf 파일 또는 서버 커맨드 라인에서만 설정 가능하다.

각 라운드에 쓰기 된 dirty 버퍼의 수는 최근 라운드 중에 서버 프로세스가 필요로 했던 새 버퍼 수를 근거로 한다. 최근의 평균 요구량은 다음 라운드에서 필요한 버퍼 추정치에 도달하도록 bgwriter_lru_multiplier를 곱한다. 깨끗하고 재사용 가능한 버퍼 수가 지정된 개수가 될 때까지 dirty 버퍼는 쓰여진다. (그렇더라도 라운드당 bgwriter_lru_maxpages 이상의 버퍼는 쓰여지지 않는다.) 따라서, 1.0 설정은 정확히 필요한 버퍼 수를 기록하는 “just in time” 정책을 나타낸다. 더 큰 값을 설정하면 수요 급증에 대비할 수 있는 반면, 더 작은 값은 쓰기를 서버 프로세스가 처리하도록 일부러 미처리 상태로 방치한다. 기본값은 2.0이다. 이 매개 변수는 postgresql.conf 파일 또는 서버 커맨드 라인에서만 설정 가능하다.

Whenever more than this amount of data has been written by the background writer, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an fsync is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 512kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) BLCKSZ change the default and maximum.) This parameter can only be set in the postgresql.conf file or on the server command line.

PostgreSQL가 동시에 실행 가능할 것으로 예상하는 동시 디스크 I/O 실행 수를 설정한다. 이 값을 올리면 각 PostgreSQL 세션이 병렬 초기화를 시도하는 I/O 실행 수가 늘어난다. 허용 범위는 1 ~ 1000, 또는 비동기 I/O 요청의 실행을 비활성화하는 0이다. 현재, 이 설정은 비트맵 힙 스캔에만 영향을 미친다.

일반 하드 디스크인 경우, 이 설정을 위한 권장 시작점은 데이터베이스에서 사용되는 RAID 0 스트라이프 또는 RAID 1 미러를 환경 설정하는 개별 드라이브 수이다. (RAID 5의 경우 패리티 드라이브 수는 계산하지 않는다. ) 그러나 동시 세션에서 여러 개의 쿼리가 실행된 상태에서 데이터베이스가 매우 바쁠 경우, 디스크 배열을 busy 상태로 유지하기 위해서는 적은 값도 충분하다. 디스크를 busy한 상태로 만들기 위해 필요 이상으로 큰 값을 설정하면 CPU 오버헤드만 가중된다. SSD나 기타 메모리 기반 스토리지인 경우는 동시 요청이 빈번할 수 있다, 이런 경우는 이 값을 수백으로 지정하는 것이 더 효과적이다.

비동기 I/O는 효과적인 posix_fadvise 함수에 따라 달라지며, 이것이 운영 체제에 없을 수도 있다. 이 함수가 없을 경우 이 매개 변수를 0 이외의 다른 것으로 설정하면 에러가 발생한다. 일부 운영 체제(예: Solaris)에는 함수가 존재하지만 실제로는 아무것도 하지 않는다.

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 ALTER TABLESPACE).

Similar to effective_io_concurrency, but used for maintenance work that is done on behalf of many client sessions.

The default is 10 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 ALTER TABLESPACE).

시스템이 지원할 수 있는 백그라운드 프로세스의 최대 수를 설정한다. 이 매개 변수는 서버 시작 시에만 설정 가능하다. 기본값은 8.

대기 서버 실행 중에는 이 매개 변수를 마스터 서버 값보다 크거나 같게 설정해야 한다. 그렇지 않으면 대기 서버에서 쿼리가 허용되지 않는다.

이 설정값을 바꾼다면, max_parallel_workers, max_parallel_maintenance_workers 값과 max_parallel_workers_per_gather 값도 같이 고려해야 한다.

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. 기본값은 2이며, 0으로 지정하면 병렬 쿼리를 사용하지 않는다.

병렬 쿼리는 상당히 많은 자원을 소모할 수 있으며, 그 이유는 각 작업 프로세스가 시스템에서 추가되는 사용자 세션에 완전히 분리되어, 거의 동일한 영향을 주기 때문이다. work_mem 설정과 같은 자원 사용 설정에 대한 값들은 이를 고려해야 한다. work_mem과 같은 자원 사용의 제한 설정들은 각 작업자에 따라 개별적으로 적용되며 이는 전체 사용량이 단일 프로세스보다 훨씬 더 높을 수 있음을 의미한다. 예를 들면, 4개의 작업자를 사용하는 병렬 쿼리는 CPU 시간, 메모리, I/O 대역폭으로 5배나 더 많이 사용할 수 있다.

병렬 쿼리에 대한 보다 자세한 내용은 15장에서 다룬다.

Sets the maximum number of parallel workers that can be started by a single utility command. Currently, the parallel utility commands that support the use of parallel workers are CREATE INDEX only when building a B-tree index, and VACUUM without FULL option. 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 utility operation will run with fewer workers than expected. The default value is 2. Setting this value to 0 disables the use of parallel workers by utility commands.

Note that parallel utility commands should not consume substantially more memory than equivalent non-parallel operations. This strategy differs from that of parallel query, where resource limits generally apply per worker process. Parallel utility commands treat the resource limit maintenance_work_mem as a limit to be applied to the entire utility command, regardless of the number of parallel worker processes. However, parallel utility commands may still consume substantially more CPU resources and I/O bandwidth.

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.

Whenever more than this amount of data has been written by a single backend, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an fsync is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 0, i.e., no forced writeback. (If BLCKSZ is not 8kB, the maximum value scales proportionally to it.)

Sets the minimum amount of time that a query snapshot can be used without risk of a “snapshot too old” error occurring when using the snapshot. Data that has been dead for longer than this threshold is allowed to be vacuumed away. This can help prevent bloat in the face of snapshots which remain in use for a long time. To prevent incorrect results due to cleanup of data which would otherwise be visible to the snapshot, an error is generated when the snapshot is older than this threshold and the snapshot is used to read a page which has been modified since the snapshot was built.

If this value is specified without units, it is taken as minutes. A value of -1 (the default) disables this feature, effectively setting the snapshot age limit to infinity. This parameter can only be set at server start.

Useful values for production work probably range from a small number of hours to a few days. Small values (such as 0 or 1min) are only allowed because they may sometimes be useful for testing. While a setting as high as 60d is allowed, please note that in many workloads extreme bloat or transaction ID wraparound may occur in much shorter time frames.

When this feature is enabled, freed space at the end of a relation cannot be released to the operating system, since that could remove information needed to detect the “snapshot too old” condition. All space allocated to a relation remains associated with that relation for reuse only within that relation unless explicitly freed (for example, with VACUUM FULL).

This setting does not attempt to guarantee that an error will be generated under any particular circumstances. In fact, if the correct results can be generated from (for example) a cursor which has materialized a result set, no error will be generated even if the underlying rows in the referenced table have been vacuumed away. Some tables cannot safely be vacuumed early, and so will not be affected by this setting, such as system catalogs. For such tables this setting will neither reduce bloat nor create a possibility of a “snapshot too old” error on scanning.