Solución:
Puede ver lo que hay en la caché del búfer de PostgreSQL utilizando el módulo pg_buffercache. Hice una presentación llamada “Dentro de la caché de búfer de PostgreSQL” que explica lo que está viendo y muestro algunas consultas más complicadas para ayudar a interpretar la información que acompaña a eso.
También es posible mirar el caché del sistema operativo en algunos sistemas, consulte [pg_osmem.py] por un ejemplo algo tosco.
No hay forma de borrar los cachés fácilmente. En Linux, puede detener el servidor de la base de datos y utilizar la función drop_caches para borrar la memoria caché del sistema operativo; asegúrese de prestar atención a la advertencia allí para ejecutar la sincronización primero.
No he visto ningún comando para vaciar los cachés en PostgreSQL. Lo que ve es probablemente solo índices normales y cachés de datos que se leen desde el disco y se mantienen en la memoria. tanto por postgresql como por las cachés del sistema operativo. Para deshacerme de todo eso, la única forma que conozco:
Lo que debes hacer es:
- Apague el servidor de la base de datos (pg_ctl,
sudo service postgresql stop,sudo systemctl stop postgresql, etc.) -
echo 3 > /proc/sys/vm/drop_cachesEsto borrará los cachés de archivos / bloques del sistema operativo, lo que es muy importante, aunque no sé cómo hacerlo en otros sistemas operativos. (En caso de denegación del permiso, intente
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"como en esa pregunta) - Inicie el servidor de la base de datos (p. Ej.
sudo service postgresql start,sudo systemctl start postgresql)
La respuesta de Greg Smith sobre drop_caches fue muy útil. Encontré necesario detener e iniciar el servicio postgresql, además de eliminar los cachés. Aquí hay un script de shell que hace el truco. (Mi entorno es Ubuntu 14.04 y PostgreSQL 9.3).
#!/usr/bin/sudo bash
service postgresql stop
sync
echo 3 > /proc/sys/vm/drop_caches
service postgresql start
Probé con una consulta que tomó 19 segundos la primera vez y menos de 2 segundos en los intentos posteriores. Después de ejecutar este script, la consulta nuevamente tomó 19 segundos.