För sex mĂ„nader sedan â en offentlig för PostgreSQL.
Under de senaste mÄnaderna har vi gjort en rapport om den , förberett en sammanfattande baserat pÄ rekommendationer som den ger... men viktigast av allt har vi samlat era feedback och observerat verkliga anvÀndningsfall.
Och nu Àr vi redo att berÀtta om de nya funktionerna som ni kan anvÀnda.
Stöd för olika planformat
Plan frÄn loggen, tillsammans med frÄgan
Direkt frÄn konsolen markerar vi hela blocket, som börjar frÄn raden med Query Text, med alla ledande 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 vi kastar allt kopierat direkt in i fÀltet för planen, utan att dela upp nÄgot:
Resultatet ger oss ett bonus till den analyserade planen, plus fliken "kontext", dÀr vÄr frÄga presenteras i all sin prakt:
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
}
]"Oavsett om den har yttre citattecken, som pgAdmin kopierar, eller inte â vi kastar in det i samma fĂ€lt, sĂ„ fĂ„r vi det Ă€ndĂ„ vackert:
Utökad visualisering
Planning Time / Execution Time
Nu Àr det tydligare var den extra tiden gick vid frÄgekörning:
I/O Timing
Ibland stöter man pÄ en situation dÀr det i planen verkar som att det inte lÀsts eller skrivits sÀrskilt mycket resurser, men att körningstiden Àr orimligt lÄng.
HÀr mÄste man sÀga: "Oj, kanske var disken pÄ servern för överbelastad vid det tillfÀllet, sÄ det tog sÄ lÄng tid att lÀsa!" Men det Àr inte riktigt exakt...
Men man kan avgöra det helt pÄlitligt. PoÀngen Àr att bland PG-serverns konfigurationsalternativ finns det :
Inkluderar mÀtning av tid för in- och utdataoperationer. Denna parameter Àr som standard avstÀngd, eftersom det krÀver att det aktuella tidpunkten kontinuerligt frÄgas frÄn operativsystemet, vilket kan försena arbetet betydligt pÄ vissa plattformar. För att bedöma mÀtningskostnaderna pÄ din plattform kan du anvÀnda verktyget pg_test_timing. Statistik för in- och utdata kan erhÄllas genom vyerna pg_stat_database, i utdata frÄn EXPLAIN (nÀr parametern BUFFERS anvÀnds) och genom vyerna pg_stat_statements.
Denna parameter kan ocksÄ aktiveras inom en lokal session:
SET track_io_timing = TRUE;Nu kommer det trevligaste â vi har lĂ€rt oss att förstĂ„ och visa dessa data med hĂ€nsyn till alla transformationer av exekveringstrĂ€det:
HÀr kan vi se att av 0.790 ms av den totala exekveringstiden tog lÀsningen av en databas sida 0.718 ms, skrivningen av densamma 0.044 ms, och hela den övriga nyttiga aktiviteten kostade endast 0.028 ms!
Framtiden med PostgreSQL 13
Du kan bekanta dig med den fullstÀndiga översikten av nyheterna , men vi pratar specifikt om Àndringarna i planerna.
Planeringsbuffertar
Redovisningen av resurser som tilldelas planeringsarenan har fÄtt sitt uttryck Àven i en annan patch som inte Àr relaterad till pg_stat_statements. EXPLAIN med alternativet BUFFERS kommer att rapportera antalet buffertar som anvÀnts under planeringssteget:
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 dÀr sortering efter mÄnga nycklar (k1, k2, k3...) Àr nödvÀndig, kan planören nu utnyttja kunskapen om att data redan Àr sorterade efter flera av de första nycklarna (till exempel k1 och k2). I detta fall kan man undvika att om-sortera alla data igen, utan i stÀllet dela upp dem i sekventiella grupper med samma vÀrden för k1 och k2, och "delsortera" efter nyckeln k3.
PÄ sÄ sÀtt bryts hela sorteringen ner i flera sekventiella sorteringar av mindre storlek. Detta minskar den nödvÀndiga minnesmÀngden och gör det ocksÄ möjligt att returnera de första data snabbare Àn nÀr hela sorteringen À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
FörbÀttringar av UI/UX
SkÀrmdumpar, de finns överallt!
Nu finns det en möjligheten att snabbt ta en skĂ€rmdump av fliken till urklipp i full bredd och djup av fliken â "siktet" uppe till höger:
Faktiskt har de flesta bilderna för denna publikation erhÄllits just pÄ det sÀttet.
Rekommendationer pÄ noder
Det har inte bara blivit fler, utan man kan ocksÄ , genom att följa lÀnken:
Borttagning frÄn arkivet
MĂ„nga har bett om att lĂ€gga till möjligheten att "ta bort helt" Ă€ven de icke-publicerade planerna i arkivet â det rĂ€cker att trycka pĂ„ den motsvarande ikonen:
NÄvÀl, och glöm inte att vi har en , dit ni kan skriva era kommentarer och förslag.
KĂ€lla: habr.com
