Pool aastat tagasi - avalik PostgreSQL-ile.
Viimaste kuude jooksul oleme temaga tegelenud , koostas kokkuvõtte tuginedes soovitustele, mida see annab ... kuid mis kõige tähtsam, kogusime teie tagasisidet ja vaatasime tegelikke kasutusjuhtumeid.
Ja nüüd oleme valmis teile rääkima uutest funktsioonidest, mida saate kasutada.
Erinevate plaanivormingute tugi
Plaan logist koos taotlusega
Otse konsoolist valime kogu ploki, alustades reast Päringu tekst, kõigi eesmiste tühikutega:
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)
... ja visake kõik kopeeritud otse plaani väljale, midagi eraldamata:
Väljundil saame ka boonuse lahtivõetud plaanile konteksti vahekaart, kus meie taotlus esitatakse kogu oma hiilguses:
JSON ja 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
}
]"Isegi väliste jutumärkidega, nagu pgAdmin kopeerib, isegi ilma - viskame samale väljale, väljund on ilu:
Täiustatud visualiseerimine
Planeerimisaeg / Teostusaeg
Nüüd näete paremini, kuhu päringu täitmisel lisaaeg läks:
I/O ajastus
Vahel tuleb leppida olukorraga, kus ressursside osas tundub, et liiga palju ei loetud-kirjutatud, kuid näib, et teostusaeg on millegipärast ebaühtlaselt suur.
Siin tuleb öelda:Oh, ilmselt oli sel hetkel serveri ketas liiga ülekoormatud, sellepärast võttis lugemine nii kaua aega!"Aga millegipärast pole see väga täpne ...
Kuid seda saab täiesti usaldusväärselt määrata. Fakt on see, et PG-serveri konfiguratsioonivalikute hulgas on :
Lubab ajastatud I/O toimingud. See säte on vaikimisi keelatud, kuna see nõuab, et operatsioonisüsteem küsiks pidevalt praegust kellaaega, mis võib mõnel platvormil asju oluliselt aeglustada. Saate kasutada utiliiti pg_test_timing, et hinnata oma platvormi ajastuse üldkulusid. I/O statistikat saab hankida pg_stat_database vaate kaudu, EXPLAIN väljundis (kui kasutatakse parameetrit BUFFERS) ja pg_stat_statements vaate kaudu.
Selle valiku saab lubada ka kohaliku seansi ajal:
SET track_io_timing = TRUE;Noh, nüüd on parim osa see, et oleme õppinud neid andmeid mõistma ja kuvama, võttes arvesse kõiki täitmispuu teisendusi:
Siin on näha, et 0.790 ms kogu täitmisajast kulus ühe lehekülje andmete lugemiseks 0.718 ms, selle kirjutamiseks 0.044 ms ja kõigele muule kasulikule tegevusele kulus vaid 0.028 ms!
Tulevik PostgreSQL 13-ga
Täieliku ülevaate uudistest leiate siit , ja me räägime konkreetselt plaanide muudatustest.
Planeerimispuhvrid
Planeerijale eraldatud ressursside arvestamine kajastub teises paigas, mis ei ole seotud pg_stat_statementsiga. EXPLAIN valikuga PUHVERID teatab planeerimisetapis kasutatud puhvrite arvu:
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
Järkjärguline sortimine
Juhtudel, kui on vaja sortida paljude võtmete järgi (k1, k2, k3…), saab planeerija nüüd ära kasutada teadmist, et andmed on juba sorteeritud mitme esimese võtmega (nt k1 ja k2). Sel juhul ei saa te kõiki andmeid uuesti sortida, vaid jagada need järjestikusteks rühmadeks samade väärtustega k1 ja k2 ning "ümber sortida" võtmega k3.
Seega jaguneb kogu sorteerimine mitmeks järjestikuseks väiksema suurusega sorteerimiseks. See vähendab vajalikku mälumahtu ja võimaldab ka esimesed andmed tagastada enne, kui sorteerimine on lõppenud.
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 täiustused
Ekraanipildid on kõikjal!
Nüüd on igal vahekaardil võimalus kiiresti teha vahekaardilt lõikepuhvrisse ekraanipilt kogu saki laiuse ja sügavuse jaoks - "nägemine" paremal üleval:
Tegelikult saadi enamik selle väljaande pilte sel viisil.
Soovitused sõlmede kohta
Neid pole mitte ainult rohkem, vaid igaühte kohta, mida saate järgides linki:
Arhiivist eemaldamine
Mõned on palunud selleks võimet kustuta "absoluutselt" isegi plaanid, mida arhiivis ei avaldata - palun klõpsake lihtsalt vastavat ikooni:
Noh, ärgem unustagem, et meil on kuhu saate oma kommentaare ja ettepanekuid kirjutada.
Allikas: www.habr.com