PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Ottimizza l'intervallo di query del timestamp di Postgres

CLUSTER

Se intendi utilizzare CLUSTER , la sintassi visualizzata non è valida.

create CLUSTER ticket USING ticket_1_idx;

Esegui una volta:

CLUSTER ticket USING ticket_1_idx;

Questo può aiuta molto con set di risultati più grandi. Non tanto per una singola riga restituita.
Postgres ricorda quale indice utilizzare per le chiamate successive. Se la tua tabella non è di sola lettura, l'effetto si deteriora nel tempo e devi rieseguirlo a determinati intervalli:

CLUSTER ticket;

Possibilmente solo su partizioni volatili. Vedi sotto.

Tuttavia , se hai molti aggiornamenti, CLUSTER (o VACUUM FULL ) potrebbe effettivamente essere dannoso per le prestazioni. La giusta quantità di rigonfiamento consente UPDATE per posizionare nuove versioni di riga nella stessa pagina di dati ed evita la necessità di estendere fisicamente il file sottostante nel sistema operativo troppo spesso. Puoi utilizzare un FILLFACTOR accuratamente ottimizzato per ottenere il meglio da entrambi i mondi:

  • Fattore di riempimento per un indice sequenziale che è PK

pg_repack

CLUSTER prende un blocco esclusivo sul tavolo, che potrebbe essere un problema in un ambiente multiutente. Citando il manuale:

Quando una tabella viene raggruppata, viene visualizzato un ACCESS EXCLUSIVE blocco viene acquisito su di esso. Ciò impedisce qualsiasi altra operazione sul database (sia di lettura che di scrittura ) dall'operare sul tavolo fino al CLUSTER è finito.

Enfasi in grassetto mio. Considera l'alternativa pg_repack :

A differenza di CLUSTER e VACUUM FULL funziona in linea, senza mantenere un blocco esclusivo sulle tabelle elaborate durante l'elaborazione. pg_repack è efficiente per l'avvio, con prestazioni paragonabili all'utilizzo di CLUSTER direttamente.

e:

pg_repack deve prendere un blocco esclusivo al termine della riorganizzazione.

La versione 1.3.1 funziona con:

PostgreSQL 8.3, 8.4, 9.0, 9.1, 9.2, 9.3, 9.4

La versione 1.4.2 funziona con:

PostgreSQL 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 10

Interrogazione

La query è abbastanza semplice da non causare problemi di prestazioni di per sé.

Tuttavia, una parola sulla correttezza :Il BETWEEN costruire include frontiere. La tua query seleziona tutto il 19 dicembre, più record dal 20 dicembre, 00:00 ore. È un estremamente improbabile Requisiti. È probabile che tu voglia davvero:

SELECT *
FROM   ticket 
WHERE  created >= '2012-12-19 0:0'
AND    created <  '2012-12-20 0:0';

Prestazioni

Prima di tutto, chiedi:

Perché sta selezionando la scansione sequenziale?

Il tuo EXPLAIN l'output mostra chiaramente una Scansione indice , non una scansione sequenziale della tabella. Ci deve essere una sorta di malinteso.

Se ti viene richiesto di ottenere prestazioni migliori, potresti essere in grado di migliorare le cose. Ma le informazioni di base necessarie non sono nella domanda. Le possibili opzioni includono:

  • Puoi interrogare solo le colonne obbligatorie invece di * per ridurre i costi di trasferimento (ed eventualmente altri vantaggi in termini di prestazioni).

  • Potresti esaminare il partizionamento e metti pratici intervalli di tempo in tabelle separate. Aggiungi indici alle partizioni secondo necessità.

  • Se il partizionamento non è un'opzione, un'altra tecnica correlata ma meno intrusiva sarebbe quella di aggiungere uno o più indici parziali .
    Ad esempio, se interroghi principalmente il mese corrente , potresti creare il seguente indice parziale:

    CREATE INDEX ticket_created_idx ON ticket(created)
WHERE created >= '2012-12-01 00:00:00'::timestamp;

    CREATE un nuovo indice a destra prima l'inizio di un nuovo mese. Puoi facilmente automatizzare l'attività con un cron job. Facoltativamente DROP indici parziali per vecchi mesi dopo.

  • Mantieni l'indice totale in aggiunta per CLUSTER (che non può operare su indici parziali). Se i vecchi record non cambiano mai, il partizionamento delle tabelle aiuterebbe molto questa attività, dal momento che devi solo riordinare le partizioni più recenti. Inoltre, se i record non cambiano mai, probabilmente non hai bisogno di CLUSTER .

Se combini gli ultimi due passaggi, le prestazioni dovrebbero essere eccezionali.

Nozioni di base sulle prestazioni

Potrebbe mancare una delle basi. Si applicano tutti i consueti consigli sulle prestazioni:

  • https://wiki.postgresql.org/wiki/Slow_Query_Questions
  • https://wiki.postgresql.org/wiki/Performance_Optimization