PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Cache de hits partagé dans postgreSQL

shared hit signifie essentiellement que la valeur a déjà été mise en cache dans la mémoire principale de l'ordinateur et qu'il n'était pas nécessaire de la lire à partir du disque dur.

L'accès à la mémoire principale (RAM) est beaucoup plus rapide que la lecture des valeurs du disque dur. Et c'est pourquoi la requête est plus rapide, plus elle a de résultats de partage.

Immédiatement après le démarrage de Postgres, aucune des données n'est disponible dans la mémoire principale (RAM) et tout doit être lu à partir du disque dur.

Considérez cette étape d'un plan d'exécution :

  ->  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 partie "Buffers:shared read=2818" signifie que 2818 blocs (chaque 8k) ont dû être lus depuis le disque dur (et cela a pris 48ms - j'ai un SSD). Ces 2818 blocs ont été stockés dans le cache (le "tampons partagés ") afin que la prochaine fois qu'ils seront nécessaires, la base de données n'ait pas besoin de les lire (à nouveau) à partir du disque dur (lent).

Lorsque je relance cette instruction, le plan devient :

  ->  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

Ce qui signifie que ces 2818 blocs que la déclaration précédente étaient toujours dans la mémoire principale (=RAM) et que Postgres n'avait pas besoin de les lire à partir du disque dur.

"mémoire" fait toujours référence à la mémoire principale (RAM) intégrée à l'ordinateur et directement accessible au CPU - par opposition au "stockage externe".

Il existe plusieurs présentations sur la façon dont Postgres gère les tampons partagés :