Nusu mwaka uliopita - umma kwa PostgreSQL.
Katika miezi iliyopita tumefanya juu yake , alitayarisha muhtasari kulingana na mapendekezo ambayo inatoa ... lakini muhimu zaidi, tulikusanya maoni yako na kuangalia kesi za matumizi halisi.
Na sasa tuko tayari kukuambia kuhusu vipengele vipya ambavyo unaweza kutumia.
Msaada kwa miundo tofauti ya mpango
Panga kutoka kwa logi, pamoja na ombi
Moja kwa moja kutoka kwa console, tunachagua block nzima, kuanzia mstari na Nakala ya Swali, na nafasi zote zinazoongoza:
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)
... na kutupa kila kitu kilichonakiliwa moja kwa moja kwenye uwanja wa mpango, bila kutenganisha chochote:
Katika pato, tunapata pia bonasi kwa mpango uliovunjwa kichupo cha muktadha, ambapo ombi letu linawasilishwa kwa utukufu wake wote:
JSON na 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
}
]"Hata na nukuu za nje, kama nakala za pgAdmin, hata bila - tunatupa kwenye uwanja huo huo, matokeo ni uzuri:
Taswira ya hali ya juu
Wakati wa Kupanga / Wakati wa Utekelezaji
Sasa unaweza kuona vyema wakati wa ziada ulipoenda wakati wa kutekeleza hoja:
Muda wa I/O
Wakati mwingine unapaswa kushughulika na hali ambapo, kwa suala la rasilimali, inaonekana kwamba sio sana kusoma na kuandikwa, lakini inaonekana kwamba wakati wa utekelezaji ni incongruously kubwa kwa sababu fulani.
Inapaswa kusemwa hapa:Lo, labda, wakati huo diski kwenye seva ilikuwa imejaa sana, ndiyo sababu ilichukua muda mrefu kusoma!"Lakini kwa njia fulani sio sahihi sana ...
Lakini inaweza kuamua kwa uhakika kabisa. Ukweli ni kwamba kati ya chaguzi za usanidi wa seva ya PG kuna :
Huwasha utendakazi wa I/O ulioratibiwa. Mipangilio hii imezimwa kwa chaguomsingi, kwa kuwa inahitaji mfumo wa uendeshaji kuuliza mara kwa mara wakati wa sasa, ambao unaweza kupunguza kasi ya mambo kwa kiasi kikubwa kwenye baadhi ya mifumo. Unaweza kutumia pg_test_timing matumizi ili kukadiria matumizi ya muda kwenye jukwaa lako. Takwimu za I/O zinaweza kupatikana kupitia mwonekano wa pg_stat_database, katika pato la EXPLAIN (wakati parameta ya BUFFERS inatumiwa) na kupitia mwonekano wa pg_stat_statements.
Chaguo hili pia linaweza kuwezeshwa ndani ya kipindi cha ndani:
SET track_io_timing = TRUE;Kweli, sasa sehemu bora ni kwamba tumejifunza kuelewa na kuonyesha data hii, kwa kuzingatia mabadiliko yote ya mti wa utekelezaji:
Hapa unaweza kuona kwamba kati ya 0.790ms ya muda wote wa utekelezaji, 0.718ms ilichukua kusoma ukurasa mmoja wa data, 0.044ms - kuiandika, na 0.028ms pekee ndiyo iliyotumiwa kwa shughuli nyingine zote muhimu!
Baadaye na PostgreSQL 13
Kwa muhtasari kamili wa kile kipya, ona , na tunazungumza haswa juu ya mabadiliko katika mipango.
Kupanga bafa
Uhasibu wa rasilimali zilizogawiwa kwa kipanga ratiba huonyeshwa katika kiraka kingine ambacho hakihusiani na pg_stat_statements. ELEZA kwa chaguo la BUFFERS itaripoti idadi ya vihifadhi vilivyotumika wakati wa awamu ya kupanga:
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
Aina ya kuongezeka
Katika hali ambapo kupanga kwa vitufe vingi (k1, k2, k3β¦) kunahitajika, mpangaji sasa anaweza kuchukua fursa ya kujua kwamba data tayari imepangwa kwa funguo kadhaa za kwanza (km k1 na k2). Katika kesi hii, huwezi kupanga tena data zote, lakini uzigawanye katika vikundi vilivyofuatana na maadili sawa ya k1 na k2, na "kupanga upya" kwa ufunguo wa k3.
Kwa hivyo, upangaji mzima hugawanyika katika mipangilio kadhaa mfululizo ya saizi ndogo. Hii inapunguza kiasi cha kumbukumbu kinachohitajika, na pia inakuwezesha kurudisha data ya kwanza kabla ya upangaji kukamilika.
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
Maboresho ya UI/UX
Picha za skrini ziko kila mahali!
Sasa kwenye kila kichupo kuna fursa ya haraka chukua picha ya skrini ya kichupo kwenye ubao wa kunakili kwa upana mzima na kina cha kichupo - "kuona" juu kulia:
Kwa kweli, picha nyingi za chapisho hili zilipatikana kwa njia hii.
Mapendekezo kwenye nodi
Kuna si tu zaidi yao, lakini kuhusu kila mmoja unaweza kwa kufuata kiungo:
Inaondoa kwenye kumbukumbu
Wengine wameomba uwezo wa kufuta "kabisa" hata mipango ambayo haijachapishwa kwenye kumbukumbu - tafadhali, bonyeza tu ikoni inayolingana:
Naam, tusisahau kwamba tuna ambapo unaweza kuandika maoni na mapendekezo yako.
Chanzo: mapenzi.com