Impatto di CLUSTER sulle prestazioni

Sto cercando di ottimizzare il mio database Postgres 9.2 per velocizzare le query con limiti di data.

Ho una timestampcolonna, ma per lo più chiedo un giorno, quindi ho creato un indice timestampper l' dateanalisi:

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

Ora, per aumentare una prestazione CLUSTER footabella I usando l'indice sopra:

CLUSTER foo USING foo_my_timestamp_idx;

Secondo il manuale su SQL-CLUSTER , la tabella

viene riordinato fisicamente in base alle informazioni dell'indice

Mi chiedo se ci sia un impatto sulle prestazioni per altre query usando un PK di tabella (diciamo id_foo). Ci sono degli aspetti negativi?

Sì, ci possono essere aspetti negativi. Se un'altra query esamina un diverso segmento di dati non determinato dalla data, potrebbe verificarsi un calo delle prestazioni se le righe sono ora distribuite su più pagine di dati. Proprio come i profitti della tua prima query. Dipende completamente dalle informazioni non presenti nella tua domanda.

altre query usando un PK di tabella (diciamo id_foo)

Potrebbe essere qualsiasi cosa . Dipende da cosa hai e da cosa esatti . L'interrogazione di una singola riga non è influenzata in alcun modo, ma potrebbero esserlo più righe.

Essere consapevoli del fatto che CLUSTERriscrive la tabella in condizioni incontaminate come VACUUM FULLfa (rimuove le tuple morte, compatta la dimensione fisica della tabella, riscrive gli indici) Quindi potresti vedere un effetto positivo immediato sulle prestazioni di lettura indipendentemente dall'ordinamento. (Proprio come faresti con te VACUUM FULL.)
Dopo CLUSTER, potresti voler eseguire una semplice VACUUMtabella per aggiornare anche la mappa di visibilità , il che può consentire scansioni solo indice.

Tutti i vantaggi di CLUSTERridursi con la frequenza di scrittura.

Inoltre, se si dispone di molti aggiornamenti alla tabella, si CLUSTERpuò effettivamente compromettere le prestazioni di scrittura rimuovendo "wiggle room" per gli aggiornamenti HOT nella stessa pagina di dati. Potresti essere in grado di contrastare tale effetto con FILLFACTORun'impostazione inferiore a 100. Ancora una volta, dipende dalla località delle righe aggiornate, ecc.

Relazionato:

• Ottimizzazione dell'indice con le date

Ad ogni modo, probabilmente non vorrei indicizzare e raggruppare my_timestamp::date, ma my_timestampdirettamente. Niente di perso, qualcosa di guadagnato. Il cast è molto economico, ma è ancora più economico non farlo affatto. E l'indice può supportare più query.

CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);

Anche se a dateoccupa solo 4 byte sul disco e timestampoccupa 8 byte, la differenza viene in genere persa per il riempimento di allineamento per il caso, ed entrambi gli indici hanno esattamente le stesse dimensioni.

L'ordine di più righe nello stesso giorno risultante dall'indice delle espressioni è arbitrario. Possono esserci ancora due timestamp identici, ma con 6 cifre frazionarie che è normalmente molto improbabile. A parte questo, ottieni un ordine deterministico di righe, che può avere vari vantaggi.

Ho anche lasciato cadere la DESCparola chiave poiché Postgres è in grado di leggere gli indici all'indietro praticamente in avanti. (L'ordinamento è importante per gli indici a più colonne, però!) Altro:

• Ottimizzazione delle query su un intervallo di timestamp (due colonne)

Invece di:

SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';

Ora useresti:

SELECT * FROM foo
WHERE  my_timestamp >= '2016-07-25'  -- this is a timestamp literal now
WHERE  my_timestamp <  '2016-07-26';

Stesse prestazioni.

Se non è necessario il componente temporale della colonna a tutti , convertire la colonna a date...

Come tornare indietro CLUSTER?

CLUSTERsu una singola tabella può essere eseguito il rollback ROLLBACKcome qualsiasi altro comando regolare purché la transazione non sia stata impegnata.

Tuttavia, cito il manuale :

CLUSTERsenza alcun parametro richiude tutte le tabelle precedentemente raggruppate nel database corrente di proprietà dell'utente chiamante o tutte tali tabelle se chiamate da un superutente. Questa forma di CLUSTERnon può essere eseguita all'interno di un blocco di transazione.

È sempre possibile eseguire CLUSTERun indice diverso per modificare nuovamente l'ordine fisico delle righe.