Virun engem hallwe Joer - ëffentlech zu PostgreSQL.
An de leschte Méint hu mir iwwer him gemaach , e Resumé virbereet baséiert op den Empfehlungen, déi et erausginn ... awer am wichtegsten, mir hunn Äre Feedback gesammelt an déi richteg Benotzungsfäll gekuckt.
An elo si mir prett Iech iwwer déi nei Features ze soen déi Dir benotze kënnt.
Ënnerstëtzung fir verschidde Planformater
Plan aus dem Logbuch, zesumme mat der Demande
Direkt vun der Konsol wielt mir de ganze Spär, ugefaange vun der Linn mat Query Text, mat all féierende Plazen:
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)
... a geheien alles kopéiert direkt an den Terrain fir de Plang, ouni eppes ze trennen:
Beim Ausgang kréie mir och e Bonus zum ofgebauten Plang Kontext Tab, wou eis Ufro an all senger Herrlechkeet presentéiert gëtt:
JSON an 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
}
]"Och mat externen Zitater, als pgAdmin Kopien, och ouni - mir werfen am selwechte Feld, d'Ausgab ass Schéinheet:
Fortgeschratt Visualiséierung
Planungszäit / Ausféierung Zäit
Elo kënnt Dir besser gesinn wou d'Verlängerung Zäit goung wann Dir d'Ufro ausféiert:
I/O Timing
Heiansdo musst Dir mat enger Situatioun këmmeren, wou et a punkto Ressourcen schéngt, datt net ze vill gelies a geschriwwe gouf, awer et schéngt datt d'Ausféierungszäit aus iergendengem Grond onkongruent grouss ass.
Et muss hei gesot ginn:Oh, wahrscheinlech, dee Moment war den Disk um Server ze iwwerlaascht, dofir huet et sou laang gedauert fir ze liesen!"Awer iergendwéi ass et net ganz korrekt ...
Mee et kann absolut zouverlässeg bestëmmt ginn. D'Tatsaach ass datt ënnert de Konfiguratiounsoptioune vum PG Server et sinn :
Aktivéiert timed I/O Operatiounen. Dës Astellung ass standardiséiert ausgeschalt, well et erfuerdert datt de Betribssystem dauernd d'aktuell Zäit ufroen, wat d'Saachen op e puer Plattforme wesentlech verlangsamen. Dir kënnt d'pg_test_timing Utility benotzen fir d'Iwwerhead vum Timing op Ärer Plattform ze schätzen. I/O Statistike kënnen duerch d'pg_stat_database Vue kritt ginn, am EXPLAIN Output (wann de BUFFERS Parameter benotzt gëtt) an duerch d'pg_stat_statements Vue.
Dës Optioun kann och bannent enger lokaler Sessioun aktivéiert ginn:
SET track_io_timing = TRUE;Gutt, elo ass dee beschten Deel datt mir geléiert hunn dës Donnéeën ze verstoen an ze weisen, andeems Dir all Transformatiounen vum Ausféierungsbaum berücksichtegt:
Hei kënnt Dir gesinn datt vun 0.790ms vun der Gesamtausféierungszäit, 0.718ms eng Säit vun Daten gelies hunn, 0.044ms - et schreift, an nëmmen 0.028ms gouf op all aner nëtzlech Aktivitéit verbruecht!
Zukunft mat PostgreSQL 13
Fir e kompletten Iwwerbléck iwwer wat nei ass, kuckt , a mir schwätzen speziell iwwer Ännerungen an Pläng.
Planung Puffer
Comptablesmethod fir Ressourcen, déi dem Scheduler zougewisen sinn, spigelt sech an engem anere Patch deen net mat pg_stat_statements verbonnen ass. EXPLAIN mat der BUFFERS Optioun wäert d'Zuel vun de Puffer berichten déi während der Planungsphase benotzt ginn:
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 Zort
A Fäll wou d'Zortéierung vu ville Schlësselen (k1, k2, k3 ...) gebraucht gëtt, kann de Planner elo profitéieren dovun ze wëssen datt d'Donnéeë scho mat e puer vun den éischte Schlësselen (z.B. k1 a k2) zortéiert sinn. An dësem Fall kënnt Dir net all d'Donnéeën nei sortéieren, awer se a successive Gruppen opdeelen mat de selwechte Wäerter vu k1 an k2, a "neesortéieren" se mam Schlëssel k3.
Sou gëtt déi ganz Sortéierung an e puer successive Sortéierunge vun enger méi klenger Gréisst opgedeelt. Dëst reduzéiert d'Quantitéit vun Erënnerung néideg, an erlaabt Iech och déi éischt Donnéeën zréck ier all Zortéieren fäerdeg ass.
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 Verbesserungen
Screenshots sinn iwwerall!
Elo op all Tab ass et eng Méiglechkeet fir séier huelt Screenshot vum Tab op de Clipboard fir déi ganz Breet an Déift vum Tab - "Siicht" riets uewen:
Eigentlech sinn déi meescht vun de Biller fir dës Publikatioun op dës Manéier kritt.
Recommandatiounen op Wirbelen
Et ginn net nëmme méi vun hinnen, mä iwwer all eent Dir kënnt andeems Dir de Link follegt:
Ewechzehuelen aus dem Archiv
E puer hu gefrot fir d'Fäegkeet ze läschen "absolut" souguer Pläng déi net am Archiv publizéiert ginn - w.e.g. klickt einfach op déi entspriechend Ikon:
Ma, loosst eis net vergiessen datt mir et hunn wou Dir kënnt Är Kommentaren a Virschléi schreiwen.
Source: will.com