file_extend_method

Definition PG 18 manual

Specifies the method used to extend data files during bulk operations such as COPY. The first available option is used as the default, depending on the operating system:

The write_zeros method is always used when data files are extended by 8 blocks or fewer.

How it works

file_extend_method chooses how PostgreSQL grows relation files during bulk extension: posix_fallocate when available or explicit zero writes. Extensions of eight blocks or fewer still use zero writes.

The first supported method is platform dependent. posix_fallocate reserves space without writing every block, but unsupported file systems silently fall back; on current BTRFS it can disable compression for the file.

This affects allocation behavior and bulk-write latency, not WAL durability. Storage reservations, sparse-file behavior, compression, and copy-on-write semantics vary by file system. Its SIGHUP context allows configuration reload without a server restart.

Operational considerations

Changing file_extend_method without applying its documented unit and configuration context.

Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.

Assuming a configured value guarantees operating-system or storage behavior.

Failing to retest startup, failover, and workload latency after the change.

Workload guidance

OLAP: Large allocations or bulk I/O can make file_extend_method visible, but platform capability is the first gate. Benchmark on production-equivalent storage and include failure/fallback behavior.

OLTP: Keep file_extend_method at the detected/default value unless operating-system support and a controlled benchmark justify a change. Validate startup and recovery on the exact kernel and file system.

SMALL: Avoid nondefault file_extend_method on a small or heterogeneous fleet unless it solves a verified platform issue. Portability and reliable startup usually outweigh a speculative gain.