Sei mesi fa — un servizio pubblico per PostgreSQL.
Nel corso dei mesi trascorsi, abbiamo realizzato , abbiamo preparato un articolo riassuntivo basato sulle raccomandazioni che fornisce… ma la cosa più importante è che abbiamo raccolto i vostri feedback e monitorato casi d'uso reali.
E ora siamo pronti a raccontarvi delle nuove funzionalità di cui potete usufruire.
Supporto per diversi formati di piani
Piano dal log, insieme alla query
Selezioniamo direttamente dalla console l'intero blocco, a partire dalla riga con Query Text, con tutti gli spazi iniziali:
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
… e incolliamo tutto il copiato direttamente nel campo per il piano, senza separare nulla:
Ultimamente otteniamo come bonus al piano analizzato anche una scheda 'contesto', dove la nostra query è presentata in tutto il suo splendore:
JSON e YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"Che con le virgolette esterne, come copia pgAdmin, o senza — mettiamo nello stesso campo, il risultato è perfetto:
Visualizzazione avanzata
Tempo di pianificazione / Tempo di esecuzione
Ora è più chiaro dove è andato a finire il tempo extra durante l'esecuzione della query:
Tempi I/O
A volte ci si può trovare in una situazione in cui nel piano sembrava che non ci fossero stati troppi I/O, ma il tempo di esecuzione sembra inappropriatamente lungo.
In questo caso si deve dire: "Oh, probabilmente in quel momento il disco sul server era troppo sovraccarico, quindi la lettura è durata così a lungo!" Ma non è molto preciso…
Ma è possibile determinarlo in modo assolutamente affidabile. Infatti, tra le opzioni di configurazione del server PG, c'è :
Include la misurazione del tempo delle operazioni di input/output. Questo parametro è disabilitato per impostazione predefinita, poiché richiede di interrogare costantemente il sistema operativo per l'ora attuale, il che può rallentare notevolmente le prestazioni su alcune piattaforme. Per valutare l'impatto della misurazione del tempo sulla tua piattaforma, puoi utilizzare lo strumento pg_test_timing. Le statistiche di input/output possono essere ottenute tramite la vista pg_stat_database, nell'output di EXPLAIN (quando si utilizza il parametro BUFFERS) e attraverso la vista pg_stat_statements.
Questo parametro può essere attivato anche a livello di sessione locale:
SET track_io_timing = TRUE;Ma ora arriva la parte più interessante: abbiamo imparato a comprendere e visualizzare questi dati tenendo conto di tutte le trasformazioni dell'albero di esecuzione:
Qui si può notare che, su 0.790ms di tempo di esecuzione, 0.718ms sono stati impiegati per leggere una pagina di dati, 0.044ms per scriverla, mentre solo 0.028ms sono stati spesi per tutta la restante attività utile!
Il futuro con PostgreSQL 13
Puoi trovare una panoramica completa delle novità , mentre noi ci concentreremo specificamente sulle modifiche nei piani.
Planning buffers
La gestione delle risorse allocate al pianificatore è riflessa anche in un altro patch non legato a pg_stat_statements. L'EXPLAIN con l'opzione BUFFERS comunicherà il numero di buffer utilizzati nella fase di pianificazione:
Seq Scan su pg_class (righe attuali=386 cicli=1) Buffer: hit condivisi=9 letti=4 Tempo di Pianificazione: 0.782 ms Buffer: hit condivisi=103 letti=11 Tempo di Esecuzione: 0.219 ms
Ordinamento incrementale
In situazioni in cui è necessaria l'ordinamento per molte chiavi (k1, k2, k3…), il pianificatore ora può sfruttare la conoscenza che i dati sono già ordinati per alcune delle prime chiavi (ad esempio, k1 e k2). In questo caso non è necessario riordinare nuovamente tutti i dati, ma è possibile suddividerli in gruppi successivi con valori identici per k1 e k2 e “riordinare” in base alla chiave k3.
In questo modo, l'intero processo di ordinamento si suddivide in più ordinamenti successivi di dimensioni ridotte. Questo riduce la quantità di memoria necessaria e consente di restituire i primi dati prima che l'intero ordinamento sia completamente eseguito.
Ordinamento Incrementale (righe attuali=2949857 cicli=1) Chiave di Ordinamento: ticket_no, passenger_id Chiave Presortita: ticket_no Gruppi di Ordinamento Completo: 92184 Metodo di Ordinamento: quicksort Memoria: media=31kB picco=31kB -> Scansione Indice utilizzando tickets_pkey sui tickets (righe attuali=2949857 cicli=1) Tempo di Pianificazione: 2.137 ms Tempo di Esecuzione: 2230.019 ms
Miglioramenti UI/UX
Screenshot, sono ovunque!
Ora in ogni scheda è possibile rapidamente prendere uno screenshot della scheda negli appunti a tutta larghezza e profondità della scheda — «mira» in alto a destra:
Infatti, la maggior parte delle immagini per questa pubblicazione è stata ottenuta proprio in questo modo.
Raccomandazioni sui nodi
Non solo ce ne sono di più, ma per ciascuna si può , seguendo il link:
Rimozione dall'archivio
Alcuni hanno richiesto molto di aggiungere la possibilità di rimuovere «completamente» anche i piani non pubblicabili in archivio — per favore, è sufficiente cliccare sull'icona corrispondente:
E non dimentichiamo che abbiamo una , dove è possibile inviare i propri commenti e suggerimenti.
Fonte: habr.com
