Pred pol leta - javni v PostgreSQL.
V preteklih mesecih smo naredili o njem , pripravil povzetek na podlagi priporočil, ki jih daje ... najpomembneje pa je, da smo zbrali vaše povratne informacije in si ogledali dejanske primere uporabe.
In zdaj smo pripravljeni, da vam povemo o novih funkcijah, ki jih lahko uporabljate.
Podpora za različne oblike načrtov
Načrt iz dnevnika, skupaj z zahtevo
Neposredno s konzole izberemo celoten blok, začenši z vrstico z Besedilo poizvedbe, z vsemi začetnimi presledki:
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)
... in vrzite vse kopirano neposredno v polje za načrt, ne da bi kar koli ločili:
Na izhodu dobimo tudi bonus za razstavljen načrt kontekstni zavihek, kjer je naša zahteva predstavljena v vsem svojem sijaju:
JSON in 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
}
]"Tudi z zunanjimi narekovaji, kot kopije pgAdmin, tudi brez - vržemo v isto polje, je rezultat lep:
Napredna vizualizacija
Čas načrtovanja / čas izvedbe
Zdaj lahko bolje vidite, kam je šel dodaten čas pri izvajanju poizvedbe:
Čas V/I
Včasih se moraš soočiti s situacijo, ko se glede na vire zdi, da ni bilo preveč prebranega in napisanega, vendar se zdi, da je čas izvedbe iz nekega razloga neprimerno dolg.
Tukaj je treba povedati:Oh, verjetno je bil v tistem trenutku disk na strežniku preobremenjen, zato je branje trajalo tako dolgo!"Ampak nekako ni zelo natančno ...
Ampak to je mogoče določiti popolnoma zanesljivo. Dejstvo je, da med konfiguracijskimi možnostmi strežnika PG obstajajo :
Omogoča časovno določene V/I operacije. Ta nastavitev je privzeto onemogočena, saj zahteva, da operacijski sistem nenehno poizveduje o trenutnem času, kar lahko na nekaterih platformah znatno upočasni stvari. Uporabite lahko pripomoček pg_test_timing, da ocenite režijske stroške merjenja časa na vaši platformi. V/I statistiko lahko pridobite prek pogleda pg_stat_database, v izhodu EXPLAIN (ko je uporabljen parameter BUFFERS) in prek pogleda pg_stat_statements.
To možnost je mogoče omogočiti tudi znotraj lokalne seje:
SET track_io_timing = TRUE;No, najboljši del pa je, da smo se naučili razumeti in prikazati te podatke ob upoštevanju vseh transformacij izvedbenega drevesa:
Tukaj lahko vidite, da je od 0.790 ms skupnega časa izvajanja 0.718 ms branje ene strani podatkov, 0.044 ms pisanje in le 0.028 ms je bilo porabljeno za vse druge koristne dejavnosti!
Prihodnost s PostgreSQL 13
Za popoln pregled novosti glejte , konkretno pa govorimo o spremembah načrtov.
Načrtovalni blažilniki
Obračunavanje virov, dodeljenih razporejevalniku, se odraža v drugem popravku, ki ni povezan s pg_stat_statements. EXPLAIN z možnostjo BUFFERS bo poročal o številu medpomnilnikov, uporabljenih v fazi načrtovanja:
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
Prirastno razvrščanje
V primerih, ko je potrebno razvrščanje po več ključih (k1, k2, k3…), lahko načrtovalec zdaj izkoristi dejstvo, da so podatki že razvrščeni po več prvih ključih (npr. k1 in k2). V tem primeru ne morete ponovno razvrstiti vseh podatkov na novo, ampak jih razdelite v zaporedne skupine z enakima vrednostma k1 in k2 ter jih "prerazvrstite" s ključem k3.
Tako se celotno razvrščanje razdeli na več zaporednih razvrstitev manjše velikosti. To zmanjša količino potrebnega pomnilnika in vam omogoča, da vrnete prve podatke, preden je celotno razvrščanje končano.
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
Izboljšave UI/UX
Posnetki zaslona so povsod!
Zdaj je na vsakem zavihku možnost hitrega naredi posnetek zaslona zavihka v odložišče za celotno širino in globino jezička - "vid" desno-zgoraj:
Pravzaprav je večina slik za to publikacijo pridobljenih na ta način.
Priporočila glede vozlišč
Ne samo, da jih je več, ampak o vsakem lahko tako, da sledite povezavi:
Odstranjevanje iz arhiva
Nekateri so zahtevali možnost, da izbriši "absolutno" tudi načrti, ki niso objavljeni v arhivu - kliknite na ustrezno ikono:
No, ne pozabimo, da imamo kjer lahko napišete svoje pripombe in predloge.
Vir: www.habr.com