Shared hit cache in postgreSQL

Sto sperimentando con il comando EXPLAIN e sto provando a scoprire cos'è lo shared hit.Shared hit cache in postgreSQL

Seq Scan on foo (cost=0.00..18334.00 rows=1000000 width=37) (actual time=0.030..90.500 rows=1000000 loops=1) 
    Buffers: shared hit=512 read=7822 
Total runtime: 116.080 ms

Ho notato che il numero di hit più condiviso è il più veloce in cui viene eseguita una query. Ma cos'è? Per quanto ho ottenuto, shared read sta leggendo solo da una memoria fisica come RAID o SSD. Ma perché lo shared hit è più veloce? È memorizzato nella RAM o dove?

fonte

2015-10-02 St.Antario

'hit' condiviso misurare i valori cam e da memoria (condivisa) e dove non letti dall'hard disk –

@a_horse_with_no_name Com'è possibile che i valori provengano dalla memoria (condivisa nel caso) senza leggere la memoria? Non capisco ... –

@a_horse_with_no_name È [che] (https://en.wikipedia.org/wiki/Shared_memory_%28interprocess_communication%29) il concetto di memoria condivisa di cui hai parlato? –

shared hit significa essenzialmente che il valore è già stato memorizzato nella cache nella memoria principale del computer e non è stato necessario leggerlo dal disco rigido.

L'accesso alla memoria principale (RAM) è molto più veloce della lettura dei valori dal disco rigido. Ed è per questo che la query è più veloce e più successi di condivisione ha.

Immediatamente dopo l'avvio di Postgres, nessuno dei dati è disponibile nella memoria principale (RAM) e tutto deve essere letto dal disco rigido.

consideri questo passaggio da un piano di esecuzione:

-> 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 "buffer: condiviso in lettura = 2818" significa che 2818 blocchi (ogni 8k) dovevano essere letti dal disco rigido (e che ha preso 48MS - Ho un SSD). Questi 2818 blocchi sono stati memorizzati nella cache (il "shared buffers") in modo che la volta successiva che sono necessari il database non ha bisogno di leggerli (di nuovo) dal disco rigido (lento).

Quando ho ri-eseguire questa affermazione il piano cambia in:

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

Il che significa che i 2818 blocchi che l'istruzione precedente erano ancora nella memoria principale (= RAM) e Postgres non ha bisogno di leggere li dal disco rigido.

"memoria" si riferisce sempre alla memoria principale (RAM) incorporata nel computer e direttamente accessibile alla CPU - al contrario di "memoria esterna".

Ci sono diverse presentazioni su come Postgres gestisce i buffer condivisi:

fonte

2015-10-02 13:41:46

Shared hit cache in postgreSQL

risposta

Problemi correlati