Re: Seq Scan como lo procesa Postgresql

mauricio pullabuestan escribió:
> Tengo una tabla que tiene al rededor de 250 mil registros y pesa unos
> 170 mb, solamente tiene su PK

> Tengo entendido que Postgres sube toda la tabla a memoria es decir 170
> mb para hacer Seq Scan y si ejecuta un promedio de 1000 estaríamos,
> haciendo que  Postgres se leyera 170 Gb, esta es la forma en que lo
> hace o lo hace de otra manera?

No, no se leen 170 GB. Hay tres optimizaciones involucradas:
1. el caché del sistema operativo
2. shared_buffers
3. synchronized_scans

Primero postgres pide al OS las páginas, con lo cual quedan en el caché.
Luego las páginas se leen desde el caché del OS a shared_buffers[*].
En el segundo seqscan se pedirán páginas al OS, que ya las tiene en
memoria, así que no hay que leerlas de disco.

Ahora, si lanzas un seqscan y ya hay otro en ejecución, el segundo
empieza desde justo la parte que está leyendo el primero (se
sincroniza) -- así se optimizan las lecturas desde disco.

[*] hay que aclarar que en un seqscan se usan máximo, si mal no
recuerdo, 4MB de shared buffers, para evitar vaciar shared_buffers de
páginas de otras tablas cuando se hace un seqscan de una tabla muy
grande.

> La consulta demora al rededor de 0.28 segundos, aparentemente
> inofensiva pero esta cargando de trabajo innecesario al servidor, se 
> creo un indice filtrado y se corrigió el problema.

Usa EXPLAIN (ANALYZE, BUFFERS) para saber qué tanto se usa de
shared_buffers.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services