Ett halvår sedan - offentlig till PostgreSQL.
Under de senaste månaderna har vi gjort med honom , gjorde en sammanfattning baserat på rekommendationerna som den ger ut ... men viktigast av allt, vi samlade in din feedback och tittade på verkliga användningsfall.
Och nu är vi redo att berätta om de nya funktionerna som du kan använda.
Stöd för olika planformat
Planera från loggen, tillsammans med begäran
Direkt från konsolen väljer vi hela blocket, med början från raden med Frågetext, med alla inledande mellanslag:
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)
... och kasta allt kopierat direkt i fältet för planen, utan att separera något:
Vid utgången får vi även en bonus på den nedmonterade planen kontextfliken, där vår begäran presenteras i all sin glans:
JSON och 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
}
]"Även med externa citat, som pgAdmin-kopior, även utan - vi slänger i samma fält, resultatet är skönhet:
Avancerad visualisering
Planeringstid / Utförandetid
Nu kan du bättre se var den extra tiden tog vägen när du körde frågan:
I/O-timing
Ibland måste man hantera en situation där det resursmässigt verkar som att det inte har lästs och skrivits för mycket, men det verkar som att genomförandetiden av någon anledning är oförenlig lång.
Det måste sägas här:Åh, förmodligen, i det ögonblicket var disken på servern för överbelastad, det var därför det tog så lång tid att läsa!"Men på något sätt är det inte särskilt exakt ...
Men det kan fastställas helt tillförlitligt. Faktum är att det finns bland konfigurationsalternativen för PG-servern :
Aktiverar tidsinställda I/O-operationer. Den här inställningen är inaktiverad som standard, eftersom den kräver att operativsystemet ständigt frågar efter aktuell tid, vilket kan sakta ner avsevärt på vissa plattformar. Du kan använda verktyget pg_test_timing för att uppskatta omkostnader för timing på din plattform. I/O-statistik kan erhållas via vyn pg_stat_database, i EXPLAIN-utgången (när parametern BUFFERS används) och genom vyn pg_stat_statements.
Det här alternativet kan också aktiveras inom en lokal session:
SET track_io_timing = TRUE;Nåväl, nu är det bästa att vi har lärt oss att förstå och visa dessa data, med hänsyn till alla transformationer av exekveringsträdet:
Här kan du se att av 0.790 ms av den totala exekveringstiden tog 0.718 ms att läsa en sida med data, 0.044 ms - att skriva den, och endast 0.028 ms spenderades på all annan användbar aktivitet!
Framtid med PostgreSQL 13
För en fullständig översikt över vad som är nytt, se , och vi talar specifikt om förändringar i planer.
Planeringsbuffertar
Redovisning av resurser som allokerats till schemaläggaren återspeglas i en annan patch som inte är relaterad till pg_stat_statements. EXPLAIN med alternativet BUFFARE kommer att rapportera antalet buffertar som används under planeringsfasen:
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
Inkrementell sortering
I de fall sortering efter många nycklar (k1, k2, k3…) behövs, kan planeraren nu dra fördel av att veta att data redan är sorterad efter flera av de första nycklarna (t.ex. k1 och k2). I det här fallet kan du inte sortera om alla data på nytt, utan dela upp dem i på varandra följande grupper med samma värden på k1 och k2, och "omsortera" dem med nyckeln k3.
Således delas hela sorteringen upp i flera successiva sorteringar av mindre storlek. Detta minskar mängden minne som krävs och låter dig även returnera den första datan innan all sortering är klar.
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
UI/UX-förbättringar
Skärmdumpar finns överallt!
Nu på varje flik finns möjlighet att snabbt ta skärmdump av fliken till urklipp för hela flikens bredd och djup - "syn" höger upp:
De flesta bilderna till denna publikation erhölls faktiskt på detta sätt.
Rekommendationer på noder
Det finns inte bara fler av dem, utan om var och en kan du genom att följa länken:
Tar bort från arkivet
Vissa har bett om förmågan att ta bort "absolut" även planer som inte publiceras i arkivet - klicka bara på motsvarande ikon:
Nåväl, låt oss inte glömma att vi har där du kan skriva dina kommentarer och förslag.
Källa: will.com