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
