Establece la cantidad de memoria que el servidor de base de datos utiliza para los búferes de memoria compartida. El valor predeterminado es normalmente 128 megabytes (128MB), pero puede ser menor si la configuración de tu kernel no lo soporta (según lo determinado durante initdb). Esta configuración debe ser de al menos 128 kilobytes. Sin embargo, normalmente se necesitan configuraciones significativamente más altas que el mínimo para obtener un buen rendimiento. Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. (Los valores no predeterminados de BLCKSZ cambian el valor mínimo). Este parámetro solo se puede establecer al inicio del servidor.

Si tienes un servidor de base de datos dedicado con 1GB o más de RAM, un valor inicial razonable para shared_buffers es el 25% de la memoria de tu sistema. Hay algunas cargas de trabajo donde configuraciones incluso más grandes para shared_buffers son efectivas, pero debido a que PostgreSQL también depende de la caché del sistema operativo, es poco probable que una asignación de más del 40% de la RAM a shared_buffers funcione mejor que una cantidad menor. Las configuraciones más grandes para shared_buffers normalmente requieren un aumento correspondiente en max_wal_size, con el fin de repartir el proceso de escritura de grandes cantidades de datos nuevos o modificados durante un período de tiempo más largo.

En sistemas con menos de 1GB of RAM, es apropiado un porcentaje menor de RAM, para dejar espacio adecuado para el sistema operativo.

Controla si se solicitan páginas gigantes (huge pages) para la región de memoria compartida principal. Los valores válidos son try (el valor predeterminado), on y off. Este parámetro solo se puede establecer al inicio del servidor. Con huge_pages configurado en try, el servidor intentará solicitar páginas gigantes, pero volverá al valor predeterminado si eso falla. Con on, el fallo al solicitar páginas gigantes evitará que el servidor se inicie. Con off, no se solicitarán páginas gigantes. El estado real de las páginas gigantes se indica mediante la variable del servidor huge_pages_status.

Actualmente, esta configuración solo se soporta en Linux y Windows. La configuración se ignora en otros sistemas cuando se establece en try. En Linux, solo se soporta cuando shared_memory_type está configurado en mmap (el valor predeterminado).

El uso de páginas gigantes da como resultado tablas de páginas más pequeñas y menos tiempo de CPU dedicado a la gestión de memoria, aumentando el rendimiento. Para más detalles sobre el uso de páginas gigantes en Linux, consulta la Section 18.4.5.

Las páginas gigantes se conocen como «large pages» en Windows. Para usarlas, necesitas asignar el derecho de usuario “Lock pages in memory” a la cuenta de usuario de Windows que ejecuta PostgreSQL. Puedes usar la herramienta de Directiva de grupo de Windows (gpedit.msc) para asignar el derecho de usuario “Lock pages in memory”. Para iniciar el servidor de base de datos en la línea de comandos como un proceso independiente, no como un servicio de Windows, el símbolo del sistema debe ejecutarse como administrador o el Control de cuentas de usuario (UAC) debe estar deshabilitado. Cuando el UAC está habilitado, el símbolo del sistema normal revoca el derecho de usuario “Lock pages in memory” al iniciarse.

Ten en cuenta que esta configuración solo afecta a la región de memoria compartida principal. Los sistemas operativos como Linux, FreeBSD e Illumos también pueden usar páginas gigantes (también conocidas como páginas “super” o páginas “large”) automáticamente para la asignación de memoria normal, sin una solicitud explícita de PostgreSQL. En Linux, esto se llama “transparent huge pages” (THP). Se sabe que esa característica causa degradación del rendimiento con PostgreSQL para algunos usuarios en algunas versiones de Linux, por lo que actualmente se desaconseja su uso (a diferencia del uso explícito de huge_pages).

Controla el tamaño de las páginas gigantes, cuando están habilitadas con huge_pages. El valor predeterminado es cero (0). Cuando se establece en 0, se utilizará el tamaño de página gigante predeterminado en el sistema. Este parámetro solo se puede establecer al inicio del servidor.

Algunos tamaños de página comúnmente disponibles en arquitecturas de servidores modernas de 64 bits incluyen: 2MB y 1GB (Intel y AMD), 16MB y 16GB (IBM POWER), y 64kB, 2MB, 32MB y 1GB (ARM). Para más información sobre el uso y soporte, consulta la Section 18.4.5.

Las configuraciones no predeterminadas actualmente solo se soportan en Linux.

Establece la cantidad máxima de memoria utilizada para los búferes temporales dentro de cada sesión de base de datos. Estos son búferes locales de la sesión que se usan solo para el acceso a tablas temporales. Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es ocho megabytes (8MB). (Si BLCKSZ no es 8kB, el valor predeterminado se escala proporcionalmente a este). Esta configuración se puede cambiar dentro de sesiones individuales, pero solo antes del primer uso de tablas temporales dentro de la sesión; los intentos posteriores de cambiar el valor no tendrán efecto en esa sesión.

Una sesión asignará búferes temporales según sea necesario hasta el límite dado por temp_buffers. El coste de establecer un valor grande en sesiones que realmente no necesitan muchos búferes temporales es solo un descriptor de búfer, o unos 64 bytes, por cada incremento en temp_buffers. Sin embargo, si un búfer se utiliza realmente, se consumirán 8192 bytes adicionales para él (o en general, BLCKSZ bytes).

Establece el número máximo de transacciones que pueden estar en el estado «preparada» (prepared) simultáneamente (consulta la PREPARE TRANSACTION). Establecer este parámetro en cero (que es el valor predeterminado) deshabilita la característica de transacciones preparadas. Este parámetro solo se puede establecer al inicio del servidor.

Si no estás planeando usar transacciones preparadas, este parámetro debe establecerse en cero para evitar la creación accidental de transacciones preparadas. Si estás usando transacciones preparadas, probablemente querrás que max_prepared_transactions sea al menos tan grande como max_connections, para que cada sesión pueda tener una transacción preparada pendiente.

Al ejecutar un servidor en espera (standby), debes establecer este parámetro en el mismo valor o en uno superior al del servidor primario. De lo contrario, no se permitirán consultas en el servidor en espera.

Establece la cantidad máxima base de memoria que utilizará una operación de consulta (como una ordenación o una tabla hash) antes de escribir en archivos de disco temporales. Si este valor se especifica sin unidades, se toma como kilobytes. El valor predeterminado es cuatro megabytes (4MB). Ten en cuenta que una consulta compleja podría realizar varias operaciones de ordenación y de hash al mismo tiempo, y a cada operación generalmente se le permite usar tanta memoria como especifica este valor antes de que comience a escribir datos en archivos temporales. Además, varias sesiones en ejecución podrían estar realizando tales operaciones simultáneamente. Por lo tanto, la memoria total utilizada podría ser muchas veces el valor de work_mem; es necesario tener en cuenta este hecho al elegir el valor. Las operaciones de ordenación se utilizan para ORDER BY, DISTINCT y merge joins. Las tablas hash se utilizan en hash joins, agregación basada en hash, nodos de memoize y procesamiento basado en hash de subconsultas IN.

Las operaciones basadas en hash son generalmente más sensibles a la disponibilidad de memoria que las operaciones equivalentes basadas en ordenación. El límite de memoria para una tabla hash se calcula multiplicando work_mem por hash_mem_multiplier. Esto hace posible que las operaciones basadas en hash utilicen una cantidad de memoria que supera la cantidad base habitual de work_mem.

Se utiliza para calcular la cantidad máxima de memoria que las operaciones basadas en hash pueden utilizar. El límite final se determina multiplicando work_mem por hash_mem_multiplier. El valor predeterminado es 2.0, lo que hace que las operaciones basadas en hash utilicen el doble de la cantidad base habitual de work_mem.

Considera aumentar hash_mem_multiplier en entornos donde el desbordamiento (spilling) a disco por operaciones de consulta ocurre con regularidad, especialmente cuando simplemente aumentar work_mem produce presión de memoria (la presión de memoria normalmente toma la forma de errores intermitentes de falta de memoria). La configuración predeterminada de 2.0 suele ser efectiva con cargas de trabajo mixtas. Las configuraciones más altas en el rango de 2.0 - 8.0 o más pueden ser efectivas en entornos donde work_mem ya se ha aumentado a 40MB o más.

Especifica la cantidad máxima de memoria que utilizarán las operaciones de mantenimiento, como VACUUM, CREATE INDEX y ALTER TABLE ADD FOREIGN KEY. Si este valor se especifica sin unidades, se toma como kilobytes. El valor predeterminado es 64 megabytes (64MB). Dado que solo una de estas operaciones se puede ejecutar a la vez en una sesión de base de datos, y una instalación normalmente no tiene muchas de ellas ejecutándose simultáneamente, es seguro establecer este valor significativamente más grande que work_mem. Las configuraciones más grandes podrían mejorar el rendimiento para el vacuuming y para restaurar volcados de bases de datos.

Ten en cuenta que cuando se ejecuta el autovacuum, se puede asignar hasta autovacuum_max_workers veces esta memoria, así que ten cuidado de no establecer el valor predeterminado demasiado alto. Puede ser útil controlar esto configurando por separado autovacuum_work_mem.

Especifica la cantidad máxima de memoria que utilizará cada proceso autovacuum worker. Si este valor se especifica sin unidades, se toma como kilobytes. El valor predeterminado es -1, lo que indica que se debe usar el valor de maintenance_work_mem en su lugar. La configuración no tiene efecto en el comportamiento de VACUUM cuando se ejecuta en otros contextos. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Especifica el tamaño de la estrategia de acceso al búfer (Buffer Access Strategy) utilizada por los comandos VACUUM y ANALYZE. Una configuración de 0 permitirá que la operación utilice cualquier número de shared_buffers. De lo contrario, los tamaños válidos oscilan entre 128 kB y 16 GB. Si el tamaño especificado supera 1/8 del tamaño de shared_buffers, el tamaño se limita silenciosamente a ese valor. El valor predeterminado es 2MB. Si este valor se especifica sin unidades, se toma como kilobytes. Este parámetro se puede establecer en cualquier momento. Se puede anular para VACUUM and ANALYZE al pasar la opción BUFFER_USAGE_LIMIT. Las configuraciones más altas pueden permitir que VACUUM y ANALYZE se ejecuten más rápidamente, pero tener una configuración demasiado grande puede hacer que se desalojen demasiadas páginas útiles de los búferes compartidos.

Especifica la cantidad máxima de memoria que utilizará la decodificación lógica, antes de que algunos de los cambios decodificados se escriban en el disco local. Esto limita la cantidad de memoria utilizada por las conexiones de replicación en streaming lógica. El valor predeterminado es 64 megabytes (64MB). Dado que cada conexión de replicación solo utiliza un único búfer de este tamaño, y una instalación normalmente no tiene muchas de tales conexiones simultáneamente (según lo limitado por max_wal_senders), es seguro establecer este valor significativamente más alto que work_mem, reduciendo la cantidad de cambios decodificados escritos en el disco.

Especifica la cantidad de memoria a utilizar para almacenar en caché el contenido de pg_commit_ts (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 0, lo que solicita shared_buffers/512 hasta 1024 bloques, pero no menos de 16 bloques. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_multixact/members (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 32. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_multixact/offsets (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 16. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_notify (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 16. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_serial (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 32. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_subtrans (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 0, lo que solicita shared_buffers/512 hasta 1024 bloques, pero no menos de 16 bloques. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria compartida a utilizar para almacenar en caché el contenido de pg_xact (consulta la Table 66.1). Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 0, lo que solicita shared_buffers/512 hasta 1024 bloques, pero no menos de 16 bloques. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la profundidad máxima segura de la pila de ejecución del servidor. La configuración ideal para este parámetro es el límite real del tamaño de la pila impuesto por el kernel (según lo establecido por ulimit -s o su equivalente local), menos un margen de seguridad de un megabyte aproximadamente. El margen de seguridad es necesario porque la profundidad de la pila no se comprueba en cada rutina en el servidor, sino solo en rutinas potencialmente recursivas clave. Si este valor se especifica sin unidades, se toma como kilobytes. La configuración predeterminada es de dos megabytes (2MB), que es conservadoramente pequeña y con poco riesgo de causar caídas del servidor. Sin embargo, podría ser demasiado pequeña para permitir la ejecución de funciones complejas. Solo los superusuarios y los usuarios con el privilegio SET adecuado pueden cambiar esta configuración.

Establecer max_stack_depth por encima de límite real del kernel significará que una función recursiva desbocada puede hacer caer un proceso backend individual. En plataformas donde PostgreSQL puede determinar el límite del kernel, el servidor no permitirá que esta variable se establezca en un valor inseguro. Sin embargo, no todas las plataformas proporcionan la información, por lo que se recomienda precaución al seleccionar un valor.

Especifica la implementación de memoria compartida que el servidor debe usar para la región de memoria compartida principal que contiene los búferes compartidos de PostgreSQL y otros datos compartidos. Los valores posibles son mmap (para memoria compartida anónima asignada mediante mmap), sysv (para memoria compartida System V asignada mediante shmget) y windows (para memoria compartida de Windows). No todos los valores son soportados en todas las plataformas; la primera opción soportada es la predeterminada para esa plataforma. El uso de la opción sysv, que no es la predeterminada en ninguna plataforma, generalmente se desaconseja porque normalmente requiere configuraciones de kernel no predeterminadas para permitir asignaciones grandes (consulta la Section 18.4.1). Este parámetro solo se puede establecer al inicio del servidor.

Especifica la implementación de memoria compartida dinámica que el servidor debe usar. Los valores posibles son posix (para memoria compartida POSIX asignada mediante shm_open), sysv (para memoria compartida System V asignada mediante shmget), windows (para memoria compartida de Windows) y mmap (para simular memoria compartida usando archivos mapeados en memoria almacenados en el directorio de datos). No todos los valores son soportados en todas las plataformas; la primera opción soportada suele ser la predeterminada para esa plataforma. El uso de la opción mmap, que no es la predeterminada en ninguna plataforma, generalmente se desaconseja porque el sistema operativo puede escribir las páginas modificadas en el disco repetidamente, aumentando la carga de E/S del sistema; sin embargo, puede ser útil para la depuración, cuando el directorio pg_dynshmem se almacena en un disco RAM, o cuando no están disponibles otros mecanismos de memoria compartida. Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad de memoria que se debe asignar al inicio del servidor para su uso por consultas paralelas. Cuando esta región de memoria es insuficiente o se agota por consultas concurrentes, las nuevas consultas paralelas intentan asignar memoria compartida adicional temporalmente del sistema operativo utilizando el método configurado con dynamic_shared_memory_type, lo que puede ser más lento debido a los gastos generales de gestión de memoria. La memoria que se asigna al inicio con min_dynamic_shared_memory se ve afectada por la configuración de huge_pages en los sistemas operativos donde se soporta, y puede ser más probable que se beneficie de páginas más grandes en sistemas operativos donde esto se gestiona automáticamente. El valor predeterminado es 0 (ninguno). Este parámetro solo se puede establecer al inicio del servidor.

Especifica la cantidad máxima de espacio en disco que un proceso puede usar para archivos temporales, como archivos temporales de ordenación y hash, o el archivo de almacenamiento para un cursor retenido. Una transacción que intente superar este límite será cancelada. If this value is specified without units, it is taken as kilobytes. -1 (el valor predeterminado) significa que no hay límite. Solo los superusuarios y los usuarios con el privilegio SET adecuado pueden cambiar esta configuración.

Esta configuración limita el espacio total utilizado en cualquier instante por todos los archivos temporales utilizados por un proceso de PostgreSQL dado. Debe tenerse en cuenta que el espacio en disco utilizado para tablas temporales explícitas, a diferencia de los archivos temporales utilizados tras bambalinas en la ejecución de consultas, no cuenta para este límite.

Especifica el método utilizado para copiar archivos. Los valores posibles son COPY (predeterminado) y CLONE (si el soporte del sistema operativo está disponible).

Este parámetro afecta a:

CLONE utiliza las llamadas al sistema copy_file_range() (Linux, FreeBSD) o copyfile (macOS), dando al kernel la oportunidad de compartir bloques de disco o delegar el trabajo a capas inferiores en algunos sistemas de archivos.

Especifica el método utilizado para extender archivos de datos durante operaciones en bloque como COPY. La primera opción disponible se utiliza como predeterminada, dependiendo del sistema operativo:

El método write_zeros siempre se utiliza cuando los archivos de datos se extienden en 8 bloques o menos.

Especifica la cantidad máxima de páginas asignadas para la cola de NOTIFY / LISTEN. El valor predeterminado es 1048576. Para páginas de 8 KB permite consumir hasta 8 GB de espacio en disco. Este parámetro solo se puede establecer al inicio del servidor.

Establece el número máximo de archivos abiertos que cada subproceso del servidor tiene permitido abrir simultáneamente; los archivos ya abiertos en el postmaster no cuentan para este límite. El valor predeterminado es de mil archivos.

Si el kernel está imponiendo un límite seguro por proceso, no necesitas preocuparte por esta configuración. Pero en algunas plataformas (especialmente en la mayoría de los sistemas BSD), el kernel permitirá que los procesos individuales abran muchos más archivos de los que el sistema realmente puede soportar si muchos procesos intentan abrir esa cantidad de archivos. Si ves fallos de tipo “Too many open files”, intenta reducir esta configuración. Este parámetro solo se puede establecer al inicio del servidor.

Especifica el retraso entre las rondas de actividad del escritor en segundo plano. En cada ronda, el escritor realiza escrituras para un cierto número de búferes sucios (controlable por los siguientes parámetros). Luego duerme durante la duración de bgwriter_delay, y repite. Sin embargo, cuando no hay búferes sucios en el pool de búferes, entra en un sueño más prolongado independientemente de bgwriter_delay. If this value is specified without units, it is taken as milliseconds. El valor predeterminado es 200 milisegundos (200ms). Ten en cuenta que en algunos sistemas, la resolución efectiva de los retrasos de sueño es de 10 milisegundos; configurar bgwriter_delay a un valor que no sea múltiplo de 10 podría tener los mismos resultados que configurarlo al siguiente múltiplo superior de 10. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

En cada ronda, el escritor en segundo plano no escribirá más de esta cantidad de búferes. Establecer esto en cero deshabilita la escritura en segundo plano. (Ten en cuenta que los checkpoints, que son gestionados por un proceso auxiliar dedicado independiente, no se ven afectados). El valor predeterminado es 100 búferes. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

El número de búferes sucios escritos en cada ronda se basa en el número de búferes nuevos que han necesitado los procesos del servidor durante las rondas recientes. La necesidad reciente promedio se multiplica por bgwriter_lru_multiplier para llegar a una estimación del número de búferes que se necesitarán durante la siguiente ronda. Los búferes sucios se escriben hasta que haya esa cantidad de búferes limpios y reutilizables disponibles. (Sin embargo, no se escribirán más de bgwriter_lru_maxpages búferes por ronda). Por lo tanto, una configuración de 1.0 representa una política de “justo a tiempo” de escribir exactamente el número de búferes estimado que se necesitará. Los valores más grandes proporcionan cierto margen contra picos en la demanda, mientras que los valores más pequeños dejan intencionadamente que las escrituras sean realizadas por los procesos del servidor. El valor predeterminado es 2.0. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cada vez que el escritor en segundo plano haya escrito más de esta cantidad de datos, intenta forzar al sistema operativo a emitir estas escrituras al almacenamiento subyacente. Hacerlo limitará la cantidad de datos sucios en la caché de páginas del kernel, reduciendo la probabilidad de bloqueos cuando se emite un fsync al final de un checkpoint, o cuando el sistema operativo escribe datos en lotes más grandes en segundo plano. A menudo, eso dará como resultado una latencia de transacción muy reducida, pero también hay algunos casos, especialmente con cargas de trabajo que son mayores que shared_buffers pero menores que la caché de páginas del sistema operativo, donde el rendimiento podría degradarse. Esta configuración puede no tener efecto en algunas plataformas. Si este valor se especifica sin unidades, es tomado como bloques, es decir, BLCKSZ bytes, típicamente 8kB. El rango válido está entre 0, que deshabilita la escritura forzada, y 2MB. El valor predeterminado es 512kB en Linux, 0 en otros lugares. (Si BLCKSZ no es 8kB, los valores predeterminado y máximo se escalan proporcionalmente a este). Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Cada vez que un único backend haya escrito más de esta cantidad de datos, intenta forzar al sistema operativo a emitir estas escrituras al almacenamiento subyacente. Hacerlo limitará la cantidad de datos sucios en la caché de páginas del kernel, reduciendo la probabilidad de bloqueos cuando se emite un fsync al final de un checkpoint, o cuando el sistema operativo escribe datos en lotes más grandes en segundo plano. A menudo, eso dará como resultado una latencia de transacción muy reducida, pero también hay algunos casos, especialmente con cargas de trabajo que son mayores que shared_buffers pero menores que la caché de páginas del sistema operativo, donde el rendimiento podría degradarse. Esta configuración puede no tener efecto en algunas plataformas. Si este valor se especifica sin unidades, es tomado como bloques, es decir, BLCKSZ bytes, típicamente 8kB. El rango válido está entre 0, que deshabilita la escritura forzada, y 2MB. El valor predeterminado es 0, es decir, sin escritura forzada. (Si BLCKSZ no es 8kB, el valor máximo se escala proporcionalmente a este).

Establece el número de operaciones simultáneas de E/S de almacenamiento que PostgreSQL espera que se puedan ejecutar simultáneamente. Aumentar este valor incrementará el número de operaciones de E/S que cualquier sesión individual de PostgreSQL intente iniciar en paralelo. El rango permitido es de 1 a 1000, o 0 para deshabilitar la emisión de solicitudes de E/S asíncronas. El valor predeterminado es 16.

Los valores más altos tendrán un mayor impacto en el almacenamiento de mayor latencia, donde las consultas de otro modo experimentarían bloqueos notables de E/S, y en dispositivos con altos IOPs. Los valores innecesariamente altos pueden aumentar la latencia de E/S para todas las consultas en el sistema.

En sistemas con soporte para asesoramiento de lectura anticipada (prefetch advice), effective_io_concurrency también controla la distancia de lectura anticipada (prefetch distance).

Este valor se puede anular para tablas en un tablespace particular configurando el parámetro de tablespace del mismo nombre (consulta la ALTER TABLESPACE).

Similar a effective_io_concurrency, pero utilizado para el trabajo de mantenimiento que se realiza en nombre de muchas sesiones de clientes.

El valor predeterminado es 16. Este valor se puede anular para tablas en un tablespace particular configurando el parámetro de tablespace del mismo nombre (consulta la ALTER TABLESPACE).

Controla el tamaño de E/S más grande en operaciones que combinan E/S, y limita silenciosamente el parámetro configurable por el usuario io_combine_limit. Este parámetro solo se puede establecer al inicio del servidor. Si este valor se especifica sin unidades, es tomado como bloques, es decir, BLCKSZ bytes, típicamente 8kB. El tamaño máximo posible depende del sistema operativo y del tamaño de bloque, pero normalmente es de 1MB en Unix y 128kB en Windows. El valor predeterminado es 128kB.

Controla el tamaño de E/S más grande en operaciones que combinan E/S. Si se establece por encima del parámetro io_max_combine_limit, se utilizará silenciosamente el valor más bajo en su lugar, por lo que puede ser necesario aumentar ambos para incrementar el tamaño de E/S. Si este valor se especifica sin unidades, es tomado como bloques, es decir, BLCKSZ bytes, típicamente 8kB. El tamaño máximo posible depende del sistema operativo y del tamaño de bloque, pero normalmente es de 1MB en Unix y 128kB en Windows. El valor predeterminado es 128kB.

Controla el número máximo de operaciones de E/S que un proceso puede ejecutar simultáneamente.

La configuración predeterminada de -1 selecciona un número basado en shared_buffers y el número máximo de procesos (max_connections, autovacuum_worker_slots, max_worker_processes y max_wal_senders), pero no más de 64.

Este parámetro solo se puede establecer al inicio del servidor.

Selecciona el método para ejecutar E/S asíncrona. Los valores posibles son:

El valor predeterminado es worker.

Este parámetro solo se puede establecer al inicio del servidor.

Selecciona el número de procesos worker de E/S a utilizar. El valor predeterminado es 3. Este parámetro solo se puede establecer en el archivo postgresql.conf o en la línea de comandos del servidor.

Solo tiene efecto si io_method está configurado en worker.

Establece el número máximo de procesos en segundo plano que el clúster puede soportar. Este parámetro solo se puede establecer al inicio del servidor. El valor predeterminado es 8.

Al ejecutar un servidor en espera (standby), debes establecer este parámetro en el mismo valor o en uno superior al del servidor primario. De lo contrario, no se permitirán consultas en el servidor en espera.

Al cambiar este valor, considera también ajustar max_parallel_workers, max_parallel_maintenance_workers y max_parallel_workers_per_gather.

Establece el número máximo de workers que pueden ser iniciados por un único nodo Gather o Gather Merge. Los workers paralelos se toman del pool de procesos establecido por max_worker_processes, limitado por max_parallel_workers. Ten en cuenta que la cantidad solicitada de workers podría no estar realmente disponible en tiempo de ejecución. Si esto ocurre, el plan se ejecutará con menos workers de los previstos, lo que puede ser ineficiente. El valor predeterminado es 2. Establecer este valor en 0 deshabilita la ejecución de consultas paralelas.

Ten en cuenta que las consultas paralelas pueden consumir sustancialmente más recursos que las consultas no paralelas, porque cada proceso worker es un proceso completamente independiente que tiene aproximadamente el mismo impacto en el sistema que una sesión de usuario adicional. Esto debe tenerse en cuenta al elegir un valor para esta configuración, así como al configurar otras opciones que controlan la utilización de recursos, tales como work_mem. Los límites de recursos como work_mem se aplican individualmente a cada worker, lo que significa que la utilización total puede ser mucho mayor en todos los procesos de lo que sería normalmente para cualquier proceso individual. Por ejemplo, una consulta paralela que utiliza 4 workers puede usar hasta 5 veces más tiempo de CPU, memoria, ancho de banda de E/S, etc., que una consulta que no utiliza ningún worker.

Para obtener más información sobre consultas paralelas, consulta la Chapter 15.

Establece el número máximo de workers paralelos que pueden ser iniciados por un único comando de utilidad. Actualmente, los comandos de utilidad paralelos que soportan el uso de workers paralelos son CREATE INDEX al construir un índice B-tree, GIN o BRIN, y VACUUM sin la opción FULL. Los workers paralelos se toman del pool de procesos establecido por max_worker_processes, limitado por max_parallel_workers. Ten en cuenta que la cantidad solicitada de workers podría no estar realmente disponible en tiempo de ejecución. Si esto ocurre, la operación de utilidad se ejecutará con menos workers de los previstos. El valor predeterminado es 2. Establecer este valor en 0 deshabilita el uso de workers paralelos por parte de los comandos de utilidad.

Ten en cuenta que los comandos de utilidad paralelos no deberían consumir sustancialmente más memoria que las operaciones no paralelas equivalentes. Esta estrategia difiere de la de las consultas paralelas, donde los límites de recursos generalmente se aplican por proceso worker. Los comandos de utilidad paralelos tratan el límite de recursos maintenance_work_mem como un límite que se aplica a todo el comando de utilidad, independientemente del número de procesos worker paralelos. Sin embargo, los comandos de utilidad paralelos aún pueden consumir sustancialmente más recursos de CPU y ancho de banda de E/S.

Establece la cantidad máxima de workers que el clúster puede soportar para operaciones paralelas. El valor predeterminado es 8. Al aumentar o disminuir este valor, considera también ajustar max_parallel_maintenance_workers y max_parallel_workers_per_gather. Además, ten en cuenta que una configuración para este valor que sea superior a max_worker_processes no tendrá efecto, ya que los workers paralelos se toman del pool de procesos worker establecido por esa configuración.

Permite que el proceso líder ejecute el plan de consulta bajo los nodos Gather y Gather Merge en lugar de esperar a los procesos worker. El valor predeterminado es on. Establecer este valor en off reduce la probabilidad de que los workers se bloqueen porque el líder no está leyendo las tuplas lo suficientemente rápido, pero requiere que el proceso líder espere a que los procesos worker se inicien antes de que se puedan producir las primeras tuplas. El grado en que el líder puede ayudar o perjudicar el rendimiento depende del tipo de plan, el número de workers y la duración de la consulta.