Et halvt år siden - offentligt til PostgreSQL.
I løbet af de sidste måneder har vi gjort noget ved ham , udarbejdet et resumé baseret på de anbefalinger, den giver ... men vigtigst af alt, vi indsamlede din feedback og så på reelle use cases.
Og nu er vi klar til at fortælle dig om de nye funktioner, som du kan bruge.
Understøttelse af forskellige planformater
Planlæg fra loggen sammen med anmodningen
Direkte fra konsollen vælger vi hele blokken, startende fra linjen med Forespørgselstekst, med alle førende mellemrum:
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)
... og smid alt kopieret direkte i feltet til planen uden at adskille noget:
Ved udgangen får vi også en bonus til den adskilte plan kontekst fanen, hvor vores anmodning præsenteres i al sin herlighed:
JSON og 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
}
]"Selv med eksterne citater, som pgAdmin-kopier, selv uden - vi smider i det samme felt, outputtet er skønt:
Avanceret visualisering
Planlægningstid / Udførelsestid
Nu kan du bedre se, hvor den ekstra tid gik, når du udfører forespørgslen:
I/O Timing
Nogle gange er man nødt til at forholde sig til en situation, hvor det ressourcemæssigt ser ud til, at der ikke er blevet læst og skrevet for meget, men det ser ud til, at eksekveringstiden af en eller anden grund er uoverensstemmende stor.
Det skal siges her:Åh, sandsynligvis, i det øjeblik var disken på serveren for overbelastet, det er derfor, det tog så lang tid at læse!"Men på en eller anden måde er det ikke særlig præcist ...
Men det kan bestemmes helt pålideligt. Faktum er, at der er blandt konfigurationsmulighederne for PG-serveren :
Aktiverer tidsindstillede I/O-operationer. Denne indstilling er deaktiveret som standard, da den kræver, at operativsystemet konstant forespørger på det aktuelle tidspunkt, hvilket kan bremse tingene betydeligt på nogle platforme. Du kan bruge pg_test_timing-værktøjet til at estimere overhead af timing på din platform. I/O-statistik kan fås gennem pg_stat_database-visningen, i EXPLAIN-outputtet (når parameteren BUFFERS bruges) og gennem pg_stat_statements-visningen.
Denne mulighed kan også aktiveres i en lokal session:
SET track_io_timing = TRUE;Nå, nu er det bedste, at vi har lært at forstå og vise disse data under hensyntagen til alle transformationerne af udførelsestræet:
Her kan du se, at ud af 0.790 ms af den samlede udførelsestid tog 0.718 ms at læse én side med data, 0.044 ms - at skrive det, og kun 0.028 ms blev brugt på al anden nyttig aktivitet!
Fremtid med PostgreSQL 13
For et komplet overblik over, hvad der er nyt, se , og vi taler specifikt om ændringer i planer.
Planlægning af buffere
Regnskab for ressourcer allokeret til skemalæggeren afspejles i en anden patch, der ikke er relateret til pg_stat_statements. EXPLAIN med muligheden BUFFERE vil rapportere antallet af buffere, der blev brugt under planlægningsfasen:
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
Inkrementel sortering
I tilfælde hvor der er behov for sortering efter mange nøgler (k1, k2, k3...), kan planlæggeren nu drage fordel af at vide, at dataene allerede er sorteret efter flere af de første nøgler (f.eks. k1 og k2). I dette tilfælde kan du ikke sortere alle data på ny, men opdele dem i på hinanden følgende grupper med de samme værdier af k1 og k2, og "omsortere" dem med tasten k3.
Således opdeles hele sorteringen i flere successive sorteringer af en mindre størrelse. Dette reducerer mængden af hukommelse, der kræves, og giver dig også mulighed for at returnere de første data, før al sortering er fuldført.
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-forbedringer
Skærmbilleder er overalt!
Nu på hver fane er der mulighed for hurtigt tag et skærmbillede af fanen til udklipsholderen for hele fanens bredde og dybde - "syn" højre-top:
Faktisk blev de fleste af billederne til denne publikation opnået på denne måde.
Anbefalinger om noder
Der er ikke kun flere af dem, men om hver enkelt kan du ved at følge linket:
Fjerner fra arkivet
Nogle har spurgt efter evnen til slet "absolut" selv planer, der ikke er offentliggjort i arkivet - klik venligst på det tilsvarende ikon:
Nå, lad os ikke glemme, at vi har hvor du kan skrive dine kommentarer og forslag.
Kilde: www.habr.com