Caché de hits compartido en postgreSQL

shared hit esencialmente significa que el valor ya se ha almacenado en caché en la memoria principal de la computadora y no fue necesario leerlo desde el disco duro.

Acceder a la memoria principal (RAM) es mucho más rápido que leer valores del disco duro. Y es por eso que la consulta es más rápida cuantos más hits tiene.

Inmediatamente después de iniciar Postgres, ninguno de los datos está disponible en la memoria principal (RAM) y todo debe leerse desde el disco duro.

Considere este paso de un plan de ejecución:

  ->  Seq Scan on products.product_price  (cost=0.00..3210.27 rows=392273 width=0) (actual time=0.053..103.958 rows=392273 loops=1)
        Output: product_id, valid_from, valid_to, price
        Buffers: shared read=2818
        I/O Timings: read=48.382

La parte "Búferes:lectura compartida =2818" significa que se tuvieron que leer 2818 bloques (cada 8k) del disco duro (y eso tomó 48 ms, tengo un SSD). Esos 2818 bloques se almacenaron en el caché (el "búferes compartidos ") para que la próxima vez que se necesiten, la base de datos no necesite leerlos (nuevamente) desde el disco duro (lento).

Cuando vuelvo a ejecutar esa declaración, el plan cambia a:

  ->  Seq Scan on products.product_price  (cost=0.00..3210.27 rows=392273 width=0) (actual time=0.012..45.690 rows=392273 loops=1)
        Output: product_id, valid_from, valid_to, price
        Buffers: shared hit=2818

Lo que significa que esos 2818 bloques que la declaración anterior todavía estaban en la memoria principal (=RAM) y Postgres no necesitaba leerlos desde el disco duro.

"memoria" siempre se refiere a la memoria principal (RAM) integrada en la computadora y directamente accesible a la CPU, a diferencia del "almacenamiento externo".

Hay varias presentaciones sobre cómo Postgres gestiona los búferes compartidos: