Duela urte erdi - publiko PostgreSQL-ra.
Azken hilabeteetan hari buruz egin dugu , laburpena prestatu zuen ematen dituen gomendioetan oinarrituta... baina garrantzitsuena, zure iritzia jaso eta benetako erabilera kasuak aztertu ditugu.
Eta orain erabil ditzakezun aukera berriei buruz hitz egiteko prest gaude.
Plan formatu ezberdinetarako laguntza
Planifikatu erregistrotik, eskaerarekin batera
Zuzenean kontsolatik, hautatu bloke osoa, lerrotik hasita Kontsulta testua, gune nagusi guztiekin:
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)
... eta jarri zuzenean kopiatutako guztia planoaren eremuan, ezer bereizi gabe:
Bukaeran desmuntatutako planaren bonus bat lortzen dugu eta "testuingurua" fitxa, non gure eskaria bere aintza osoan aurkezten den:
JSON eta 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
}
]"Kanpoko komatxoekin, pgAdmin kopia gisa edo gabe, eremu berera botatzen dugu, eta irteera edertasuna da:
Bisualizazio aurreratua
Plangintza-denbora/Exekuzio-denbora
Orain hobeto ikus dezakezu non eman den denbora gehigarria kontsulta exekutatzen:
I/O Denboraldia
Batzuetan, egoera bati aurre egin behar zaio, non, baliabideei dagokienez, badirudi ez dela gehiegi irakurri eta idatzi, baina gauzatze-denbora inkongruenteki luzea dela dirudi.
Hemen esan behar dugu: "Oh, ziurrenik une horretan zerbitzariko diskoa gehiegi kargatuta zegoen, horregatik behar izan zen hainbeste irakurtzen!"Baina nolabait hau ez da oso zehatza...
Baina hau guztiz fidagarrian zehaztu daiteke. Kontua da PG zerbitzariaren konfigurazio aukeren artean badagoela :
I/O eragiketen tenporizazioa gaitzen du. Aukera hau lehenespenez desgaituta dago sistema eragileari uneko unean etengabe kontsultatzea eskatzen duelako, eta horrek plataforma batzuetan errendimendua nabarmen moteldu dezake. Zure plataformako denboraren kostua kalkulatzeko, pg_test_timing utilitatea erabil dezakezu. I/O estatistikak pg_stat_database ikuspegiaren bidez lor daitezke, EXPLAIN irteeran (BUFFERS parametroa erabiltzen denean) eta pg_stat_statements ikuspegiaren bidez.
Aukera hau tokiko saio batean ere gaitu daiteke:
SET track_io_timing = TRUE;Beno, orain onena da datu hauek ulertzen eta bistaratzen ikasi dugula exekuzio zuhaitzaren eraldaketa guztiak kontuan hartuta:
Hemen ikus dezakezu exekuzio-denbora osoaren 0.790 ms-tik, 0.718 ms-k datu-orri bat irakurtzen duela, 0.044 ms-k idazten hartu duela eta 0.028 ms bakarrik gastatu dela beste jarduera erabilgarria guztietan!
PostgreSQL 13-rekin etorkizuna
Berrikuntzen ikuspegi osoa aurki dezakezu , eta bereziki planen aldaketei buruz ari gara.
Plangintza-bufferak
Antolatzaileari esleitutako baliabideen kontabilitatea pg_stat_statements-ekin erlazionatuta ez dagoen beste adabaki batean islatzen da. AZALDU BUFFERS aukerarekin plangintza fasean erabilitako buffer kopuruaren berri emango du:
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
Sailkapen gehigarria
Gako askotan ordenatu behar den kasuetan (k1, k2, k3...), orain planifikatzaileak datuak lehen gako batzuetan ordenatuta daudela jakitea aprobetxa dezake orain (adibidez, k1 eta k2). Kasu honetan, ezin dituzu berriro ordenatu datu guztiak, baina k1 eta k2 balio berdinak dituzten ondoz ondoko taldeetan banatu eta k3 teklaz "ordenatu" berriro.
Beraz, sailkapen osoa tamaina txikiagoko hainbat motatan banatzen da. Horrek behar den memoria-kopurua murrizten du eta, gainera, lehen datuak ateratzeko aukera ematen du sailkapen osoa amaitu aurretik.
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 hobekuntzak
Pantaila-argazkiak, nonahi daude!
Orain fitxa bakoitzean azkar egiteko aukera dago hartu fitxaren pantaila-argazkia arbelera fitxaren zabalera eta sakonera osoa - "ikusmena" eskuin-goian:
Izan ere, argitalpen honetarako irudi gehienak horrela lortu dira.
Nodoei buruzko gomendioak
Gehiago bihurtu ez ezik, bakoitzari buruz ere hitz egin dezakezu esteka jarraituz:
Artxibotik ezabatzen
Batzuek benetan eskatu zuten aukera gehitzeko ezabatu "guztiz" artxiboan argitaratzen ez diren planak ere - mesedez egin klik dagokion ikonoan:
Beno, ez ahaztu badugula , non zure iruzkinak eta iradokizunak idatzi ditzakezu.
Iturria: www.habr.com