Prije pola godine - javni u PostgreSQL.
Tijekom proteklih mjeseci učinili smo nešto o njemu , pripremio sažetak na temelju preporuka koje daje ... ali što je najvažnije, prikupili smo vaše povratne informacije i pogledali stvarne slučajeve upotrebe.
A sada smo spremni reći vam o novim značajkama koje možete koristiti.
Podrška za različite formate planova
Plan iz dnevnika, zajedno sa zahtjevom
Izravno s konzole odabiremo cijeli blok, počevši od retka s Tekst upita, sa svim vodećim razmacima:
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)
... i bacite sve kopirano izravno u polje za plan, bez odvajanja ičega:
Na izlazu također dobivamo bonus na rastavljeni plan kontekstna kartica, gdje je naš zahtjev predstavljen u punom sjaju:
JSON i 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
}
]"Čak i s vanjskim navodnicima, kao pgAdmin kopije, čak i bez - bacamo u isto polje, rezultat je prekrasan:
Napredna vizualizacija
Vrijeme planiranja / Vrijeme izvršenja
Sada možete bolje vidjeti gdje je otišlo dodatno vrijeme prilikom izvršavanja upita:
I/O vremenski raspored
Ponekad se morate suočiti sa situacijom u kojoj se, u smislu resursa, čini da nije previše pročitano i napisano, ali se čini da je vrijeme izvršenja iz nekog razloga neshvatljivo veliko.
Ovdje treba reći:Oh, u tom trenutku je disk na serveru vjerojatno bio prezauzet, zato je čitanje trajalo tako dugo!"Ali nekako nije baš točno...
Ali može se utvrditi apsolutno pouzdano. Činjenica je da među opcijama konfiguracije PG poslužitelja postoje :
Omogućuje vremenski ograničene I/O operacije. Ova je postavka onemogućena prema zadanim postavkama jer zahtijeva od operativnog sustava da stalno ispituje trenutno vrijeme, što može znatno usporiti stvari na nekim platformama. Možete koristiti uslužni program pg_test_timing za procjenu dodatnih troškova vremena na vašoj platformi. I/O statistika se može dobiti kroz pogled pg_stat_database, u izlazu EXPLAIN (kada se koristi parametar BUFFERS) i kroz pogled pg_stat_statements.
Ova se opcija također može omogućiti unutar lokalne sesije:
SET track_io_timing = TRUE;Pa, sada je najbolji dio to što smo naučili razumjeti i prikazati ove podatke, uzimajući u obzir sve transformacije stabla izvršenja:
Ovdje možete vidjeti da je od 0.790 ms ukupnog vremena izvršenja, 0.718 ms bilo potrebno za čitanje jedne stranice podataka, 0.044 ms za pisanje, a samo 0.028 ms za sve druge korisne aktivnosti!
Budućnost s PostgreSQL 13
Za potpuni pregled novosti pogledajte , a konkretno govorimo o izmjenama planova.
Odbojnici za planiranje
Računovodstvo za resurse dodijeljene planeru odražava se u drugoj zakrpi koja nije povezana s pg_stat_statements. EXPLAIN s opcijom BUFFERS izvijestit će o broju međuspremnika korištenih tijekom faze planiranja:
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
Inkrementalno sortiranje
U slučajevima kada je potrebno sortiranje po više ključeva (k1, k2, k3…), planer sada može iskoristiti to što zna da su podaci već sortirani po nekoliko prvih ključeva (npr. k1 i k2). U tom slučaju ne možete ponovno sortirati sve podatke iznova, već ih podijeliti u uzastopne skupine s istim vrijednostima k1 i k2 i "ponovno sortirati" pomoću ključa k3.
Tako se cjelokupno razvrstavanje rastavlja na nekoliko uzastopnih razvrstavanja manje veličine. Ovo smanjuje količinu potrebne memorije, a također vam omogućuje da vratite prve podatke prije nego što se sortiranje završi.
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 poboljšanja
Snimke zaslona su posvuda!
Sada na svakoj kartici postoji mogućnost da brzo napravite snimku zaslona kartice u međuspremnik za cijelu širinu i dubinu jezička - "nišan" desno-gore:
Zapravo, većina slika za ovu publikaciju je dobivena na ovaj način.
Preporuke o čvorovima
Ne samo da ih ima više, već o svakom možete slijedeći link:
Uklanjanje iz arhive
Neki su tražili mogućnost da izbriši "apsolutno" čak i planovi koji nisu objavljeni u arhivi - samo kliknite na odgovarajuću ikonu:
Pa, nemojmo zaboraviti da imamo gdje možete napisati svoje komentare i prijedloge.
Izvor: www.habr.com