Fyrir hálfu ári - opinbert til PostgreSQL.
Undanfarna mánuði höfum við gert um hann , útbjó samantekt byggt á ráðleggingunum sem það gefur... en síðast en ekki síst, við söfnuðum athugasemdum þínum og skoðuðum raunveruleg notkunartilvik.
Og nú erum við tilbúin að tala um ný tækifæri sem þú getur notað.
Stuðningur við mismunandi áætlunarsnið
Skipuleggðu úr annálnum ásamt beiðninni
Beint frá stjórnborðinu, veldu alla blokkina, byrjaðu á línunni með Fyrirspurnartexti, með öllum fremstu rýmum:
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 settu allt afritað beint inn í áætlunarreitinn, án þess að aðskilja neitt:
Í lokin fáum við bónus á sundurtætt plan og "samhengi" flipann, þar sem beiðni okkar er sett fram í allri sinni dýrð:
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
}
]"Annaðhvort með ytri tilvitnunum, sem pgAdmin afrit, eða án - við hendum því í sama reitinn og útkoman er fegurð:
Ítarleg sjónræn
Skipulagstími/Framkvæmdartími
Nú geturðu betur séð hvar aukatíminn fór í að framkvæma fyrirspurnina:
I/O tímasetning
Stundum þarf maður að takast á við aðstæður þar sem, hvað auðlindir varðar, virðist sem ekki hafi verið of mikið lesið og skrifað, en framkvæmdartíminn virðist vera ósamræmilegur.
Hér verðum við að segja: "Ó, sennilega á því augnabliki var diskurinn á þjóninum of ofhlaðinn, þess vegna tók það svo langan tíma að lesa!„En einhvern veginn er þetta ekki mjög nákvæmt...
En þetta er hægt að ákvarða alveg áreiðanlega. Staðreyndin er sú að meðal stillingarvalkosta PG miðlara er til :
Virkjar tímasetningu I/O aðgerða. Þessi valkostur er sjálfgefið óvirkur vegna þess að það krefst stöðugrar fyrirspurnar um stýrikerfið fyrir núverandi tíma, sem getur dregið verulega úr afköstum á sumum kerfum. Til að áætla kostnað við tímasetningu á vettvangi þínum geturðu notað pg_test_timing tólið. I/O tölfræði er hægt að fá í gegnum pg_stat_database útsýnið, í EXPLAIN úttakinu (þegar BUFFERS færibreytan er notuð) og í gegnum pg_stat_statements útsýnið.
Einnig er hægt að virkja þennan valkost innan staðbundinnar lotu:
SET track_io_timing = TRUE;Jæja, það besta er að við höfum lært að skilja og birta þessi gögn með hliðsjón af öllum umbreytingum framkvæmdartrésins:
Hér geturðu séð að af 0.790 ms af heildar framkvæmdartímanum tók 0.718 ms að lesa eina gagnasíðu, 0.044 ms tók að skrifa hana og aðeins 0.028 ms var eytt í alla aðra gagnlega starfsemi!
Framtíðin með PostgreSQL 13
Þú getur fundið fullt yfirlit yfir nýjungar , og við erum sérstaklega að tala um breytingar á áætlunum.
Skipulagsstuðlarar
Bókhald fyrir tilföngum sem úthlutað er til tímaáætlunarmannsins endurspeglast í öðrum plástri sem er ekki tengdur pg_stat_statements. Útskýrðu með BUFFERS valmöguleikanum mun tilkynna fjölda biðminni sem notaðir eru á skipulagsstigi:
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
Stigvaxandi flokkun
Í þeim tilfellum þar sem þörf er á flokkun á marga lykla (k1, k2, k3...) getur skipuleggjandinn nú nýtt sér þá vitneskju að gögnin eru þegar flokkuð á nokkra af fyrstu lyklunum (til dæmis k1 og k2). Í þessu tilviki geturðu ekki endurraðað öllum gögnum aftur, heldur skipt þeim í hópa í röð með sömu gildum k1 og k2, og „endurraðað“ þeim með k3 lykli.
Þannig er allri flokkuninni skipt í nokkrar samfelldar tegundir af smærri stærð. Þetta dregur úr minni sem þarf og gerir einnig kleift að senda út fyrstu gögnin áður en allri flokkuninni er lokið.
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 endurbætur
Skjáskot, þau eru alls staðar!
Nú á hverjum flipa er tækifæri til að fljótt taktu skjáskot af flipanum á klemmuspjaldið öll breidd og dýpt flipans - "sjón" efst til hægri:
Reyndar voru flestar myndirnar fyrir þetta rit fengnar með þessum hætti.
Ráðleggingar um hnúta
Þeir eru ekki bara orðnir fleiri heldur er líka hægt að tala um hvern og einn með því að fylgja hlekknum:
Eyðir úr skjalasafni
Sumir báðu virkilega um að bæta við valkostinum eyða "alveg" jafnvel áætlanir sem eru ekki birtar í skjalasafninu - vinsamlegast smelltu bara á viðeigandi tákn:
Jæja, ekki gleyma því að við höfum , þar sem þú getur skrifað athugasemdir þínar og tillögur.
Heimild: www.habr.com