algunos parámetros para realizar el tunning de una DB PG.

tunning_postgres.md

Tunning PostgreSQL

Para PostGIS Ver http://postgis.net/docs/manual-dev/postgis-es.html

otros postgis: http://workshops.boundlessgeo.com/postgis-intro/tuning.html

Para PG: http://www.anchor.com.au/hosting/dedicated/Tuning_PostgreSQL_on_your_Dedicated_Server

Estas opciones se configuran en postgresql.conf:

constraint_exclusion

Por defecto: 1MB

Esto se utiliza generalmente para la partición de tablas. Si estás ejecutando versiones anteriores a PostgreSQL 8.4 , se establece en "on" para garantizar que el planeador de consultas optimizará. A partir de PostgreSQL 8.4, el valor predeterminado para este está ajustado a "partición", que es ideal para PostgreSQL 8.4 y superiores, ya que obligará al planificador a analizar sólo las tablas para considerar las restricciones si están en una jerarquía hereditaria y no penalizar al planificador de otra manera . 

shared_buffers

Por defecto: ~32MB

Cambialo a un valor entre 1/3 a 3/4 de la memoria RAM disponible. 

work_mem (memoria utilizada para operaciones cortas y consultas complejas)

Por defecto: 1MB

Sets the maximum number of background processes that the system can support. This parameter can only be set at server start. 

Runtime

work_mem (memoria utilizada para operaciones cortas y consultas complejas)

Por defecto: 1MB

Ajuste para bases de datos grandes, consultas complejas, mucha RAM

Ajuste para muchos usuarios concurrentes o menos RAM

Si tienes mucha RAM y algunos desarrolladores:

SET work_mem TO 1200000;

maintenance_work_mem (utilizado en operaciones de VACUUM, CREATE INDEX, etc.)

Por defecto: 16MB

Generalmente muy bajo - cierra I/O, bloquea objetos en la memoria de intercambio

Se recomienda de 32MB a 256MB en servidores de producción con mucha RAM, pero depende del numero de usuarios simultáneos. Si tienes mucha memoria RAM y algunos desarrolladores:

SET maintainence_work_mem TO 1200000;

max_parallel_workers_per_gather This setting is only available for PostgreSQL 9.6+ and will only affect PostGIS 2.3+, since only PostGIS 2.3+ supports parallel queries. If set to higher than 0, then some queries such as those involving relation functions like ST_Intersects can use multiple processes and can run more than twice as fast when doing so. If you have a lot of processors to spare, you should change the value of this to as many processors as you have. Also make sure to bump up max_worker_processes to at least as high as this number.

Por defecto: 1MB

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.