Delt hit-cache i postgreSQL

shared hit betyder i det væsentlige, at værdien allerede er blevet cachelagret i computerens hovedhukommelse, og det var ikke nødvendigt at læse denne fra harddisken.

Adgang til hovedhukommelsen (RAM) er meget hurtigere end at læse værdier fra harddisken. Og det er derfor, forespørgslen er hurtigere, jo flere share hits den har.

Umiddelbart efter start af Postgres er ingen af dataene tilgængelige i hovedhukommelsen (RAM), og alt skal læses fra harddisken.

Overvej dette trin fra en eksekveringsplan:

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

Delen "Buffers:shared read=2818" betyder, at 2818 blokke (hver 8k) skulle læses fra harddisken (og det tog 48ms - jeg har en SSD). Disse 2818 blokke blev gemt i cachen ("delte buffere "), så næste gang de er nødvendige, behøver databasen ikke at læse dem (igen) fra den (langsomme) harddisk.

Når jeg kører den erklæring igen, ændres planen til:

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

Hvilket betyder, at de 2818 blokke, som den tidligere sætning stadig var i hovedhukommelsen (=RAM), og Postgres ikke behøvede at læse dem fra harddisken.

"hukommelse" refererer altid til hovedhukommelsen (RAM) indbygget i computeren og direkte tilgængelig for CPU'en - i modsætning til "eksternt lager".

Der er flere præsentationer om, hvordan Postgres administrerer de delte buffere: