Pirms pusgada
PÄdÄjo mÄneÅ”u laikÄ mÄs esam stÄstÄ«juÅ”i par viÅu
Un tagad mÄs esam gatavi runÄt par jaunÄm iespÄjÄm, kuras varat izmantot.
Atbalsts dažÄdiem plÄnu formÄtiem
PlÄns no žurnÄla kopÄ ar pieprasÄ«jumu
TieÅ”i no konsoles atlasiet visu bloku, sÄkot no rindas ar VaicÄjuma teksts, ar visÄm sÄkuma atstarpÄm:
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)
... un ievietojiet visu nokopÄto tieÅ”i plÄna laukÄ, neko neatdalot:
BeigÄs saÅemam bonusu pie izjauktÄ plÄna un cilne "konteksts"., kur mÅ«su lÅ«gums tiek pasniegts visÄ tÄs krÄÅ”ÅumÄ:
JSON un 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
}
]"
Vai nu ar ÄrÄjÄm pÄdiÅÄm, kÄ pgAdmin kopijas, vai bez - mÄs to iemetam tajÄ paÅ”Ä laukÄ, un rezultÄts ir skaistums:
Uzlabota vizualizÄcija
PlÄnoÅ”anas laiks/Izpildes laiks
Tagad varat labÄk redzÄt, kur tika pavadÄ«ts papildu laiks vaicÄjuma izpildei:
I/O laiks
DažkÄrt nÄkas saskarties ar situÄciju, kad resursu ziÅÄ Å”Ä·iet, ka nav izlasÄ«ts un uzrakstÄ«ts pÄrÄk daudz, bet izpildes laiks Ŕķiet nesaskaÅoti garÅ”.
Å eit mums jÄsaka: "Ak, droÅ”i vien tajÄ brÄ«dÄ« servera disks bija pÄrÄk pÄrslogots, tÄpÄc lasÄ«Å”ana prasÄ«ja tik ilgu laiku!"Bet kaut kÄ tas nav ļoti precÄ«zi...
Bet to var noteikt pilnÄ«gi droÅ”i. Fakts ir tÄds, ka starp PG servera konfigurÄcijas opcijÄm ir track_io_timing
IespÄjo I/O operÄciju laiku. Å Ä« opcija pÄc noklusÄjuma ir atspÄjota, jo tai ir nepÄrtraukti jÄjautÄ operÄtÄjsistÄmai paÅ”reizÄjais laiks, kas dažÄs platformÄs var ievÄrojami palÄninÄt veiktspÄju. Lai novÄrtÄtu laika noteikÅ”anas izmaksas savÄ platformÄ, varat izmantot utilÄ«tu pg_test_timing. I/O statistiku var iegÅ«t, izmantojot pg_stat_database skatu, izejÄ EXPLAIN (ja tiek izmantots parametrs BUFFERS) un izmantojot pg_stat_statements skatu.
Å o opciju var iespÄjot arÄ« vietÄjÄ sesijÄ:
SET track_io_timing = TRUE;
Tagad labÄkais ir tas, ka mÄs esam iemÄcÄ«juÅ”ies saprast un parÄdÄ«t Å”os datus, Åemot vÄrÄ visas izpildes koka transformÄcijas:
Å eit var redzÄt, ka no 0.790 ms no kopÄjÄ izpildes laika vienas datu lapas lasÄ«Å”ana aizÅÄma 0.718 ms, rakstÄ«Å”ana aizÅÄma 0.044 ms un tikai 0.028 ms tika iztÄrÄti visÄm pÄrÄjÄm noderÄ«gajÄm darbÄ«bÄm!
NÄkotne ar PostgreSQL 13
JÅ«s varat atrast pilnu inovÄciju pÄrskatu
PlÄnoÅ”anas buferi
PlÄnotÄjam pieŔķirto resursu uzskaite ir atspoguļota citÄ ielÄpÄ, kas nav saistÄ«ts ar pg_stat_statements. EXPLAIN ar opciju BUFFERI ziÅos par plÄnoÅ”anas fÄzÄ izmantoto buferu skaitu:
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
PakÄpeniska ŔķiroÅ”ana
GadÄ«jumos, kad ir nepiecieÅ”ama ŔķiroÅ”ana pÄc daudzÄm atslÄgÄm (k1, k2, k3...), plÄnotÄjs tagad var izmantot zinÄÅ”anas, ka dati jau ir sakÄrtoti pÄc vairÄkÄm pirmajÄm atslÄgÄm (piemÄram, k1 un k2). Å ajÄ gadÄ«jumÄ jÅ«s nevarat atkÄrtoti kÄrtot visus datus, bet sadalÄ«t tos secÄ«gÄs grupÄs ar vienÄdÄm k1 un k2 vÄrtÄ«bÄm un āpÄrkÄrtotā pÄc atslÄgas k3.
TÄdÄjÄdi visa ŔķiroÅ”ana ir sadalÄ«ta vairÄkos secÄ«gos mazÄka izmÄra veidos. Tas samazina vajadzÄ«gÄs atmiÅas apjomu un ļauj arÄ« izvadÄ«t pirmos datus, pirms visa ŔķiroÅ”ana ir pabeigta.
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 uzlabojumi
EkrÄnuzÅÄmumi, tie ir visur!
Tagad katrÄ cilnÄ ir iespÄja Ätri uzÅemiet cilnes ekrÄnuzÅÄmumu starpliktuvÄ viss cilnes platums un dziļums - "skats" labajÄ augÅ”ÄjÄ stÅ«rÄ«:
PatiesÄ«bÄ lielÄkÄ daļa attÄlu Å”ai publikÄcijai tika iegÅ«ti Å”ÄdÄ veidÄ.
Ieteikumi par mezgliem
ViÅu ne tikai kļuvis vairÄk, bet par katru var arÄ« runÄt
Notiek dzÄÅ”ana no arhÄ«va
Daži cilvÄki patieÅ”Äm lÅ«dza pievienot Å”o opciju dzÄst "pilnÄ«bÄ" pat plÄni, kas nav publicÄti arhÄ«vÄ - lÅ«dzu, vienkÄrÅ”i noklikŔķiniet uz atbilstoÅ”Äs ikonas:
Nu, neaizmirstiet, ka mums ir
Avots: www.habr.com