🥇Zer isiltzen den AZALDU eta nola hitz egin dezan

Garatzaile batek bere DBAri edo negozio-jabe batek PostgreSQL aholkulari bati ekartzen dion galdera klasikoak ia beti berdina da: "Zergatik eskatzen dute hainbeste denbora datu-basean osatzeko eskaerak?"

Arrazoi multzo tradizionala:

algoritmo ez eraginkorra
hamarnaka mila erregistrotan hainbat CTE-rekin BATZEA erabakitzen duzunean
garrantzirik gabeko estatistikak
taulako datuen benetako banaketa dagoeneko ANALYZE-k azken aldian jasotakoaren oso ezberdina bada
baliabideetan "entxufatu".
eta jada ez dago CPUaren konputazio-potentzia nahikoa, gigabyte memoria etengabe ponpatzen dira edo diskoak ezin du datu-basearen "nahi" guztiak jarraitu.
blokeatzea lehian dauden prozesuetatik

Eta blokeoak harrapatzeko eta aztertzeko nahiko zailak badira, behar dugun guztiarentzat kontsulta planaerabiliz lor daitekeena AZALDU operadorea (Hobe da, noski, berehala AZALTZEA (AZTERTU, BUFFER)...) edo auto_azaldu modulua.

Baina, dokumentazio berean dioen bezala,

"Plan bat ulertzea arte bat da, eta menperatzeko esperientzia jakin bat behar da..."

Baina hori gabe egin dezakezu tresna egokia erabiltzen baduzu!

Nolakoa izan ohi da kontsulta-plan bat? Horrelako zerbait:

Index Scan using pg_class_relname_nsp_index on pg_class (actual time=0.049..0.050 rows=1 loops=1)
  Index Cond: (relname = $1)
  Filter: (oid = $0)
  Buffers: shared hit=4
  InitPlan 1 (returns $0,$1)
    ->  Limit (actual time=0.019..0.020 rows=1 loops=1)
          Buffers: shared hit=1
          ->  Seq Scan on pg_class pg_class_1 (actual time=0.015..0.015 rows=1 loops=1)
                Filter: (relkind = 'r'::"char")
                Rows Removed by Filter: 5
                Buffers: shared hit=1

edo honela:

"Append  (cost=868.60..878.95 rows=2 width=233) (actual time=0.024..0.144 rows=2 loops=1)"
"  Buffers: shared hit=3"
"  CTE cl"
"    ->  Seq Scan on pg_class  (cost=0.00..868.60 rows=9972 width=537) (actual time=0.016..0.042 rows=101 loops=1)"
"          Buffers: shared hit=3"
"  ->  Limit  (cost=0.00..0.10 rows=1 width=233) (actual time=0.023..0.024 rows=1 loops=1)"
"        Buffers: shared hit=1"
"        ->  CTE Scan on cl  (cost=0.00..997.20 rows=9972 width=233) (actual time=0.021..0.021 rows=1 loops=1)"
"              Buffers: shared hit=1"
"  ->  Limit  (cost=10.00..10.10 rows=1 width=233) (actual time=0.117..0.118 rows=1 loops=1)"
"        Buffers: shared hit=2"
"        ->  CTE Scan on cl cl_1  (cost=0.00..997.20 rows=9972 width=233) (actual time=0.001..0.104 rows=101 loops=1)"
"              Buffers: shared hit=2"
"Planning Time: 0.634 ms"
"Execution Time: 0.248 ms"

Baina "fitxatik" testuko plana irakurtzea oso zaila eta ez dago argia:

nodoan bistaratzen da batuketa azpizuhaitz baliabideen arabera
hau da, nodo jakin bat exekutatzeko zenbat denbora behar izan den ulertzeko, edo taulako irakurketa honek diskoko datuak zenbat atera dituen ulertzeko, bata bestetik nolabait kendu behar duzu.
nodoaren denbora behar da biderkatu begiztekin
bai, kenketa ez da "buruan" egin behar den eragiketa konplexuena - azken finean, exekuzio-denbora nodo baten exekuzio baten batez besteko gisa adierazten da, eta ehunka egon daitezke.
beno, eta horrek guztiak batera galdera nagusiari erantzutea galarazten digu, beraz, nork "lotura ahulena"?

Hori guztia gure ehunka garatzaileei azaltzen saiatu ginenean, kanpotik honelako itxura zuela konturatu ginen:

Eta horrek esan nahi du behar dugula...

Tool

Bertan “nor den errua eta zer egin” planaren eta eskaeraren arabera ulertzen laguntzen duten funtsezko mekanika guztiak biltzen saiatu gara. Beno, eta partekatu zure esperientziaren zati bat komunitatearekin.
Ezagutu eta erabili - azaldu.tentsorea.ru

Planen ikusgarritasuna

Erraza al da plana ulertzea honelako itxura duenean?

Seq Scan on pg_class (actual time=0.009..1.304 rows=6609 loops=1)
  Buffers: shared hit=263
Planning Time: 0.108 ms
Execution Time: 1.800 ms

Ez da benetan.

Baina honela, forma laburtuanfuntsezko adierazleak bereizten direnean, askoz argiagoa da:

Baina plana korapilatsuagoa bada, erreskatera etorriko da diagrama tarteko denbora banaketa nodoen arabera:

Beno, aukerarik zailenetarako presaka dabil laguntzeko aurrerapen taula:

Adibidez, plan batek benetako erro bat baino gehiago izan ditzakeen egoera ez-hutsak daude:

Egiturazko arrastoak

Beno, planaren egitura osoa eta bere puntu minak dagoeneko jarrita eta ikusgai badaude, zergatik ez nabarmendu garatzaileari eta azaldu "errusieraz"?

Dagoeneko bildu ditugu halako dozena pare bat gomendio txantiloiak.

Lerroz lerroko kontsulta profilatzailea

Orain, jatorrizko kontsulta aztertutako planean gainjartzen baduzu, ikus dezakezu zenbat denbora eman zen adierazpen bakoitzari - honelako zerbait:

...edo baita honela:

Parametroak eskaera batean ordezkatzea

Planari eskaera bat ez ezik, erregistroko XEHETASUN lerroko parametroak ere "eransita" badiozu, gainera kopiatu dezakezu aukeretako batean:

eskaeran balio ordezkapenarekin
zure oinarrian zuzeneko exekuzioa eta profil gehiago egiteko
```
SELECT 'const', 'param'::text;
```
balio-ordezkapenarekin PRESTATU/EXECUTE bidez
Antolatzailearen lana emulatzeko, atal parametrikoa alde batera utzi daitekeenean, adibidez, partikatutako tauletan lan egiten denean.
```
DEALLOCATE ALL;
PREPARE q(text) AS SELECT 'const', $1::text;
EXECUTE q('param'::text);
```

Planen artxiboa

Itsatsi, aztertu, partekatu lankideekin! Planak artxibatuta egongo dira eta beranduago itzul zaitezke: azaldu.tensor.ru/artxiboa

Baina ez baduzu nahi besteek zure plana ikustea, ez ahaztu "ez argitaratu artxiboan" laukia markatzea.

Hurrengo artikuluetan plan bat aztertzean sortzen diren zailtasunei eta erabakiei buruz hitz egingo dut.

Iturria: www.habr.com

AZALDU zertaz isiltzen den eta nola hitz egin