'n Half jaar gelede - publiek na PostgreSQL.
Die afgelope maande het ons oor hom gedoen , het 'n opsomming voorberei gebaseer op die aanbevelings wat dit gee ... maar die belangrikste is, ons het jou terugvoer versamel en na werklike gebruiksgevalle gekyk.
En nou is ons gereed om jou te vertel van die nuwe kenmerke wat jy kan gebruik.
Ondersteuning vir verskillende planformate
Beplan vanaf die log, saam met die versoek
Direk vanaf die konsole kies ons die hele blok, vanaf die lyn met Navraag teks, met alle voorste spasies:
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)
... en gooi alles wat gekopieer is direk in die veld vir die plan, sonder om iets te skei:
By die uitset kry ons ook 'n bonus vir die uitmekaar gehaalde plan konteks oortjie, waar ons versoek in al sy glorie aangebied word:
JSON en 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
}
]"Selfs met eksterne aanhalings, as pgAdmin-kopieΓ«, selfs sonder - ons gooi in dieselfde veld, die uitset is skoonheid:
Gevorderde visualisering
Beplanningstyd / Uitvoeringstyd
Nou kan jy beter sien waar die ekstra tyd gegaan het met die uitvoering van die navraag:
I/O Tydsberekening
Soms het jy te doen met 'n situasie waar, wat hulpbronne betref, dit blyk dat daar nie te veel gelees en geskryf is nie, maar dit blyk dat die uitvoeringstyd om een ββof ander rede onbehoorlik groot is.
Dit moet hier gesΓͺ word:O, waarskynlik, op daardie oomblik was die skyf op die bediener te oorlaai, dit is hoekom dit so lank geneem het om te lees!"Maar op een of ander manier is dit nie baie akkuraat nie ...
Maar dit kan absoluut betroubaar bepaal word. Die feit is dat daar onder die konfigurasieopsies van die PG-bediener is :
Aktiveer tydbepaalde I/O-bewerkings. Hierdie instelling is by verstek gedeaktiveer, aangesien dit vereis dat die bedryfstelsel voortdurend navraag doen oor die huidige tyd, wat dinge op sommige platforms aansienlik kan vertraag. Jy kan die pg_test_timing-nutsding gebruik om die bokoste van tydsberekening op jou platform te skat. I/O-statistieke kan verkry word deur die pg_stat_database-aansig, in die EXPLAIN-uitvoer (wanneer die BUFFERS-parameter gebruik word) en deur die pg_stat_statements-aansig.
Hierdie opsie kan ook binne 'n plaaslike sessie geaktiveer word:
SET track_io_timing = TRUE;Wel, nou is die beste deel dat ons geleer het om hierdie data te verstaan ββen te vertoon, met inagneming van al die transformasies van die uitvoeringsboom:
Hier kan jy sien dat uit 0.790ms van die totale uitvoeringstyd, 0.718ms een bladsy data gelees het, 0.044ms - om dit te skryf, en slegs 0.028ms is aan alle ander nuttige aktiwiteite bestee!
Toekoms met PostgreSQL 13
Vir 'n volledige oorsig van wat nuut is, sien , en ons praat spesifiek van veranderinge in planne.
Beplanningsbuffers
Rekeningkunde vir hulpbronne wat aan die skeduleerder toegewys is, word weerspieΓ«l in 'n ander pleister wat nie verband hou met pg_stat_statements nie. VERDUIDELIK met die BUFFERS-opsie sal die aantal buffers wat tydens die beplanningsfase gebruik is, rapporteer:
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
Inkrementele sorteer
In gevalle waar sortering volgens baie sleutels (k1, k2, k3...) nodig is, kan die beplanner nou voordeel trek uit die wete dat die data reeds volgens verskeie van die eerste sleutels (bv. k1 en k2) gesorteer is. In hierdie geval kan jy nie al die data opnuut sorteer nie, maar verdeel dit in opeenvolgende groepe met dieselfde waardes van k1 en k2, en "hersorteer" hulle volgens die sleutel k3.
Dus breek die hele sortering op in verskeie opeenvolgende sorterings van 'n kleiner grootte. Dit verminder die hoeveelheid geheue wat benodig word, en laat jou ook toe om die eerste data terug te gee voordat alle sortering voltooi is.
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-verbeterings
Skermkiekies is oral!
Nou op elke oortjie is daar 'n geleentheid om vinnig neem skermskoot van oortjie na knipbord vir die hele breedte en diepte van die oortjie - "sig" regs-bo:
Eintlik is die meeste van die prente vir hierdie publikasie op hierdie manier verkry.
Aanbevelings oor nodusse
Daar is nie net meer van hulle nie, maar oor elkeen wat jy kan deur die skakel te volg:
Verwyder tans uit die argief
Sommige het gevra vir die vermoΓ« om skrap "absoluut" selfs planne wat nie in die argief gepubliseer is nie - klik asseblief net op die ooreenstemmende ikoon:
Wel, laat ons nie vergeet dat ons het nie waar jy jou kommentaar en voorstelle kan skryf.
Bron: will.com