🥇Hyni thellë në statistikat e brendshme të PostgreSQL. Alexey Lesovsky

Transkriptimi i raportit të vitit 2015 nga Alexey Lesovsky "Hyrje e thellë në statistikat e brendshme PostgreSQL"

Mohim përgjegjësie nga autori i raportit: Vërej se ky raport është i datës Nëntor 2015 - kanë kaluar më shumë se 4 vjet dhe ka kaluar shumë kohë. Versioni 9.4 i diskutuar në raport nuk mbështetet më. Gjatë 4 viteve të fundit, janë lëshuar 5 publikime të reja në të cilat janë shfaqur shumë risi, përmirësime dhe ndryshime në lidhje me statistikat, dhe disa nga materialet janë të vjetruara dhe jo relevante. Ndërsa rishikova, u përpoqa t'i shënoj këto vende për të mos ju mashtruar lexuesin. Unë nuk i rishkruaja këto vende, ka shumë prej tyre, dhe si rezultat, do të dalë një raport krejtësisht i ndryshëm.

PostgreSQL DBMS është një mekanizëm i madh dhe ky mekanizëm përbëhet nga shumë nënsisteme, puna e koordinuar e të cilave ndikon drejtpërdrejt në performancën e DBMS. Gjatë funksionimit, mblidhen statistika dhe informacione në lidhje me funksionimin e komponentëve, gjë që ju lejon të vlerësoni efektivitetin e PostgreSQL dhe të merrni masa për të përmirësuar performancën. Megjithatë, ka shumë nga ky informacion dhe ai është paraqitur në një formë mjaft të thjeshtuar. Përpunimi i këtij informacioni dhe interpretimi i tij ndonjëherë është një detyrë krejtësisht jo e parëndësishme, dhe "kopshti zoologjik" i mjeteve dhe shërbimeve mund të ngatërrojë lehtësisht edhe një DBA të avancuar.

Mirembrema Emri im është Aleksey. Siç tha Ilya, unë do të flas për statistikat e PostgreSQL.

Statistikat e aktivitetit PostgreSQL. PostgreSQL ka dy statistika. Statistikat e aktivitetit, të cilat do të diskutohen. Dhe statistikat e planifikuesit rreth shpërndarjes së të dhënave. Unë do të flas veçanërisht për statistikat e aktivitetit PostgreSQL, të cilat na lejojnë të gjykojmë performancën dhe disi ta përmirësojmë atë.

Unë do t'ju tregoj se si të përdorni në mënyrë efektive statistikat për të zgjidhur një sërë problemesh që keni ose mund të keni.

Çfarë nuk do të jetë në raport? Në raport, nuk do të prek statistikat e planifikuesit, sepse. kjo është një temë më vete për një raport të veçantë se si ruhen të dhënat në bazën e të dhënave dhe si planifikuesi i pyetjeve merr një ide për karakteristikat cilësore dhe sasiore të këtyre të dhënave.

Dhe nuk do të ketë rishikime të mjeteve, nuk do të krahasoj një produkt me një tjetër. Nuk do të ketë reklama. Le ta heqim.

Unë dua t'ju tregoj se përdorimi i statistikave është i dobishëm. Është e nevojshme. Është i sigurt për t'u përdorur. Gjithçka që na nevojitet është SQL e rregullt dhe njohuri bazë e SQL.

Dhe ne do të flasim se cilat statistika të zgjedhim për të zgjidhur problemet.

Nëse shikojmë PostgreSQL dhe ekzekutojmë komandën në sistemin operativ për të parë proceset, do të shohim një "kuti të zezë". Do të shohim disa procese që po bëjnë diçka dhe nga emri mund të imagjinojmë afërsisht se çfarë po bëjnë atje, çfarë po bëjnë. Por, në thelb, është një kuti e zezë; ne nuk mund të shikojmë brenda.

Mund të shikojmë ngarkesën e CPU-së top, ne mund të shohim përdorimin e memories nga disa shërbime të sistemit, por nuk do të jemi në gjendje të shikojmë brenda PostgreSQL. Për këtë na duhen mjete të tjera.

Dhe duke vazhduar më tej, do t'ju tregoj se ku është shpenzuar koha. Nëse e përfaqësojmë PostgreSQL në formën e një skeme të tillë, atëherë do të jetë e mundur të përgjigjemi se ku është shpenzuar koha. Këto janë dy gjëra: është përpunimi i kërkesave të klientëve nga aplikacionet dhe detyrat e sfondit që kryen PostgreSQL për ta mbajtur atë të funksionojë.

Nëse fillojmë të shikojmë në këndin e sipërm majtas, mund të shohim se si përpunohen kërkesat e klientit. Kërkesa vjen nga aplikacioni dhe hapet një seancë klienti për punë të mëtejshme. Kërkesa i kalon planifikuesit. Planifikuesi ndërton një plan pyetjesh. E dërgon më tej për ekzekutim. Ekziston një lloj blloku i të dhënave I / O që lidhen me tabelat dhe indekset. Të dhënat e nevojshme lexohen nga disqet në memorie në një zonë të veçantë të quajtur "buffers të përbashkët". Rezultatet e pyetjes, nëse janë përditësime, fshirje, regjistrohen në regjistrin e transaksioneve në WAL. Disa informacione statistikore futen në regjistrin ose koleksionistin e statistikave. Dhe rezultati i kërkesës i kthehet klientit. Pas kësaj, klienti mund të përsërisë gjithçka me një kërkesë të re.

Po në lidhje me detyrat në sfond dhe proceset e sfondit? Ne kemi disa procese që e mbajnë bazën e të dhënave në funksion dhe funksionimin në modalitetin normal të funksionimit. Këto procese do të preken gjithashtu në raport: autovakum, pikë kontrolli, procese të lidhura me replikimin, shkrimtar i sfondit. Unë do të prek secilin prej tyre ndërsa raportoj.

Çfarë problemesh ka me statistikat?

Shumë informacion. PostgreSQL 9.4 ofron 109 metrikë për shikimin e të dhënave statistikore. Sidoqoftë, nëse baza e të dhënave ruan shumë tabela, skema, baza të të dhënave, atëherë të gjitha këto metrikë do të duhet të shumëzohen me numrin përkatës të tabelave, bazave të të dhënave. Kjo është, ka edhe më shumë informacion. Dhe është shumë e lehtë të mbytesh në të.
Problemi tjetër është se statistikat përfaqësohen me numërues. Nëse shikojmë këto statistika, do të shohim numërues vazhdimisht në rritje. Dhe nëse ka kaluar shumë kohë që nga rivendosja e statistikave, do të shohim miliarda vlera. Dhe ata nuk na thonë asgjë.
Asnjë histori. Nëse keni pasur një lloj dështimi, diçka ra 15-30 minuta më parë, nuk do të jeni në gjendje të përdorni statistikat dhe të shihni se çfarë ndodhi 15-30 minuta më parë. Ky është problem.
Mungesa e një mjeti të integruar në PostgreSQL është një problem. Zhvilluesit e kernelit nuk ofrojnë ndonjë dobi. Ata nuk kanë asgjë të tillë. Ata thjesht japin statistika në bazën e të dhënave. Përdoreni atë, bëni një kërkesë për të, çfarë të doni, pastaj bëjeni.
Meqenëse nuk ka asnjë mjet të integruar në PostgreSQL, kjo shkakton një problem tjetër. Shumë mjete të palëve të treta. Çdo kompani që ka pak a shumë duart e drejtpërdrejta po përpiqet të shkruajë programin e saj. Dhe si rezultat, komuniteti ka shumë mjete që mund t'i përdorni për të punuar me statistikat. Dhe në disa mjete ka disa veçori, në mjete të tjera nuk ka veçori të tjera, ose ka disa veçori të reja. Dhe lind një situatë që ju duhet të përdorni dy, tre ose katër mjete që mbivendosen me njëra-tjetrën dhe kanë funksione të ndryshme. Kjo është shumë e pakëndshme.

Çfarë rrjedh nga kjo? Është e rëndësishme të jeni në gjendje të merrni statistika drejtpërdrejt, në mënyrë që të mos vareni nga programet, ose t'i përmirësoni disi vetë këto programe: shtoni disa funksione për të marrë përfitimin tuaj.

Dhe keni nevojë për njohuri bazë të SQL. Për të marrë disa të dhëna nga statistikat, duhet të bëni pyetje SQL, d.m.th. duhet të dini se si bëhet përzgjedhja, bashkimi.

Statistikat na tregojnë disa gjëra. Ato mund të ndahen në kategori.

Kategoria e parë janë ngjarjet që ndodhin në bazën e të dhënave. Kjo është kur një ngjarje ndodh në bazën e të dhënave: një pyetje, një akses në tabelë, autovakum, kryerje, atëherë këto janë të gjitha ngjarje. Numëruesit që korrespondojnë me këto ngjarje janë shtuar. Dhe ne mund t'i gjurmojmë këto ngjarje.
Kategoria e dytë janë vetitë e objekteve si tabelat, bazat e të dhënave. Ata kanë veti. Kjo është madhësia e tabelave. Mund të gjurmojmë rritjen e tabelave, rritjen e indekseve. Ne mund të shohim ndryshime në dinamikë.
Dhe kategoria e tretë është koha e kaluar në ngjarje. Kërkesa është një ngjarje. Ajo ka masën e vet specifike të kohëzgjatjes. Filloi këtu, mbaroi këtu. Mund ta gjurmojmë. Ose koha e leximit të një blloku nga disku ose e shkrimit. Këto gjëra gjithashtu gjurmohen.

Burimet e statistikave janë paraqitur si më poshtë:

Në memorien e përbashkët (buferët e përbashkët) ekziston një segment për vendosjen e të dhënave statike atje, ka edhe nga ata numërues që rriten vazhdimisht kur ndodhin ngjarje të caktuara, ose lindin disa momente në funksionimin e bazës së të dhënave.
Të gjithë këta sportele nuk janë të aksesueshëm nga përdoruesi dhe as të aksesueshëm nga administratori. Këto janë gjëra të nivelit të ulët. Për t'iu qasur atyre, PostgreSQL ofron një ndërfaqe në formën e funksioneve SQL. Ne mund të bëjmë hedhje të përzgjedhura duke përdorur këto funksione dhe të marrim një lloj metrike (ose grup metrikash).
Megjithatë, përdorimi i këtyre funksioneve nuk është gjithmonë i përshtatshëm, kështu që funksionet janë baza për pamjet (VIEWs). Këto janë tabela virtuale që ofrojnë statistika për një nënsistem specifik, ose për një grup të caktuar ngjarjesh në bazën e të dhënave.
Këto pamje të integruara (VIEWs) janë ndërfaqja kryesore e përdoruesit për të punuar me statistikat. Ato janë të disponueshme si parazgjedhje pa ndonjë cilësim shtesë, mund t'i përdorni menjëherë, të shikoni, të merrni informacione nga atje. Dhe ka edhe kontribute. Kontributet janë zyrtare. Mund të instaloni paketën postgresql-contrib (për shembull, postgresql94-contrib), të ngarkoni modulin e nevojshëm në konfigurim, të specifikoni parametrat për të, të rinisni PostgreSQL dhe mund ta përdorni. (Shënim. Në varësi të shpërndarjes, në versionet e fundit të kontributit paketa është pjesë e paketës kryesore).
Dhe ka kontribut jozyrtar. Ata nuk janë të pajisur me shpërndarjen standarde PostgreSQL. Ato ose duhet të përpilohen ose të instalohen si bibliotekë. Opsionet mund të jenë shumë të ndryshme, në varësi të asaj që doli zhvilluesi i këtij kontributi jozyrtar.

Ky rrëshqitje tregon të gjitha ato pamje (VIEWs) dhe disa nga ato funksione që janë të disponueshme në PostgreSQL 9.4. Siç mund ta shohim, ka shumë prej tyre. Dhe është shumë e lehtë të ngatërrohesh nëse e përjeton për herë të parë.

Megjithatë, nëse marrim foton e mëparshme Как тратится время на PostgreSQL dhe në përputhje me këtë listë, ne marrim këtë fotografi. Ne mund të përdorim çdo pamje (VIEWs) ose çdo funksion për një qëllim ose një tjetër për të marrë statistikat përkatëse kur PostgreSQL po ekzekutohet. Dhe ne tashmë mund të marrim disa informacione në lidhje me funksionimin e nënsistemit.

Gjëja e parë që do të shikojmë është pg_stat_database. Siç mund ta shohim, kjo është një performancë. Ka shumë informacion në të. Informacioni më i larmishëm. Dhe jep njohuri shumë të dobishme për atë që po ndodh në bazën tonë të të dhënave.

Çfarë mund të marrim prej andej? Le të fillojmë me gjërat më të thjeshta.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Gjëja e parë që mund të shohim është përqindja e goditjes së cache. Përqindja e goditjes së cache është një metrikë e dobishme. Kjo ju lejon të vlerësoni se sa të dhëna merren nga memoria e përbashkët e buferave dhe sa lexohen nga disku.

Është e qartë se sa më shumë të kemi cache, aq më mirë. Ne matim këtë metrikë si përqindje. Dhe, për shembull, nëse përqindja jonë e këtyre goditjeve në cache është më shumë se 90%, atëherë kjo është mirë. Nëse bie nën 90%, atëherë nuk kemi memorie të mjaftueshme për të mbajtur kokën e nxehtë të të dhënave në memorie. Dhe për të përdorur këto të dhëna, PostgreSQL detyrohet të hyjë në disk dhe kjo është më e ngadaltë sesa nëse të dhënat do të lexoheshin nga memoria. Dhe duhet të mendoni për rritjen e memories: ose rrisni buferët e përbashkët, ose rrisni memorien e hekurt (RAM).

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

Çfarë tjetër mund të merrni nga kjo performancë? Ju mund të shihni anomalitë që ndodhin në bazën e të dhënave. Çfarë tregohet këtu? Ka angazhime, rikthime, krijimi i skedarëve të përkohshëm, madhësia e tyre, bllokimet dhe konfliktet.

Ne mund ta përdorim këtë kërkesë. Kjo SQL është mjaft e thjeshtë. Dhe ne mund t'i shohim vetë këto të dhëna.

Dhe këtu janë vlerat e pragut. Ne shikojmë raportin e angazhimeve dhe rikthimeve. Commits është një konfirmim i suksesshëm i transaksionit. Rikthimi është një rikthim, d.m.th. transaksioni bëri disa punë, tendosi bazën e të dhënave, konsideroi diçka dhe më pas ndodhi një dështim dhe rezultatet e transaksionit hidhen poshtë. dmth. numri i rikthimeve në rritje vazhdimisht është i keq. Dhe duhet t'i shmangni disi ato dhe të modifikoni kodin në mënyrë që kjo të mos ndodhë.

Konfliktet lidhen me përsëritjen. Dhe ato gjithashtu duhet të shmangen. Nëse keni disa pyetje që janë ekzekutuar në kopje dhe lindin konflikte, atëherë duhet t'i analizoni këto konflikte dhe të shihni se çfarë ndodh. Detajet mund të gjenden në regjistrat. Dhe zgjidhni konfliktet në mënyrë që kërkesat e aplikacionit të funksionojnë pa gabime.

Blloqet janë gjithashtu një situatë e keqe. Kur kërkesat po luftojnë për burime, një kërkesë hyri në një burim dhe mori bllokimin, një kërkesë e dytë hyri në burimin e dytë dhe gjithashtu mori bllokimin, dhe më pas të dyja kërkesat hynë në burimet e njëra-tjetrës dhe u bllokuan ndërsa prisnin që fqinji të lëshonte bllokimin. Kjo është gjithashtu një situatë problematike. Ato duhet të adresohen në nivelin e rishkrimit të aplikacioneve dhe të serializimit të aksesit në burime. Dhe nëse shihni që ngërçet tuaja po rriten vazhdimisht, duhet të shikoni detajet në regjistra, të analizoni situatat që janë krijuar dhe të shihni se cili është problemi.

Skedarët e përkohshëm (temp_files) janë gjithashtu të këqija. Kur një kërkesë e përdoruesit nuk ka memorie të mjaftueshme për të akomoduar të dhëna operative, të përkohshme, ajo krijon një skedar në disk. Dhe të gjitha operacionet që mund të kryejë në një tampon të përkohshëm në memorie fillojnë të kryhen në disk. Është i ngadalshëm. Kjo rrit kohën e ekzekutimit të pyetjes. Dhe klienti që dërgoi një kërkesë në PostgreSQL do të marrë një përgjigje pak më vonë. Nëse të gjitha këto operacione kryhen në memorie, Postgres do të përgjigjet shumë më shpejt dhe klienti do të presë më pak.

Pg_stat_bgwriter - Kjo pamje përshkruan funksionimin e dy nënsistemeve të sfondit PostgreSQL: kjo checkpointer и background writer.

Së pari, le të shohim pikat e kontrollit, të ashtuquajturat. checkpoints. Cilat janë pikat e kontrollit? Një pikë kontrolli është një pozicion në regjistrin e transaksioneve që tregon se të gjitha ndryshimet e të dhënave të kryera në regjistër janë sinkronizuar me sukses me të dhënat në disk. Procesi, në varësi të ngarkesës së punës dhe cilësimeve, mund të jetë i gjatë dhe kryesisht konsiston në sinkronizimin e faqeve të pista në buferat e përbashkëta me skedarët e të dhënave në disk. Për çfarë është? Nëse PostgreSQL do të hynte në disk gjatë gjithë kohës dhe do të merrte të dhëna prej andej dhe do të shkruante të dhëna në çdo akses, do të ishte i ngadalshëm. Prandaj, PostgreSQL ka një segment memorie, madhësia e të cilit varet nga parametrat në konfigurim. Postgres shpërndan të dhëna operacionale në këtë memorie për përpunim ose kërkim të mëtejshëm. Në rastin e kërkesave për ndryshim të të dhënave, ato ndryshohen. Dhe ne marrim dy versione të të dhënave. Njëra është në memorie, tjetra në disk. Dhe në mënyrë periodike ju duhet të sinkronizoni këto të dhëna. Na duhet ajo që ka ndryshuar në memorie të sinkronizohet me disk. Kjo kërkon një pikë kontrolli.

Pika e kontrollit kalon nëpër bufera të përbashkëta, shënon faqet e pista që janë të nevojshme për pikën e kontrollit. Pastaj nis një kalim të dytë nëpër buferat e përbashkëta. Dhe faqet që janë shënuar për pikë kontrolli, tashmë i sinkronizon ato. Në këtë mënyrë të dhënat sinkronizohen me diskun.

Ekzistojnë dy lloje të pikave të kontrollit. Një pikë kontrolli ekzekutohet me një afat kohor. Kjo pikë kontrolli është e dobishme dhe e mirë - checkpoint_timed. Dhe ka pika kontrolli sipas kërkesës - checkpoint required. Një pikë kontrolli e tillë ndodh kur kemi një rekord shumë të madh të të dhënave. Kemi regjistruar shumë regjistra transaksionesh. Dhe PostgreSQL beson se duhet të sinkronizojë të gjitha këto sa më shpejt që të jetë e mundur, të bëjë një pikë kontrolli dhe të vazhdojë.

Dhe nëse shikoni statistikat pg_stat_bgwriter dhe shikoni se çfarë keni checkpoint_req është shumë më i madh se checkpoint_timed, atëherë kjo është e keqe. PSE keq? Kjo do të thotë që PostgreSQL është nën stres të vazhdueshëm kur duhet të shkruajë të dhëna në disk. Pika e kontrollit sipas kohës është më pak stresuese dhe ekzekutohet sipas orarit të brendshëm dhe, si të thuash, zgjatet me kalimin e kohës. PostgreSQL ka aftësinë të ndalojë në punë dhe të mos sforcojë nënsistemin e diskut. Kjo është e dobishme për PostgreSQL. Dhe kërkesat që ekzekutohen gjatë pikës së kontrollit nuk do të përjetojnë stres nga fakti që nënsistemi i diskut është i zënë.

Dhe për të rregulluar pikën e kontrollit ka tre parametra:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Ato ju lejojnë të kontrolloni funksionimin e pikave të kontrollit. Por nuk do të ndalem në to. Ndikimi i tyre është një çështje më vete.

Warning: Versioni 9.4 i konsideruar në raport nuk është më i rëndësishëm. Në versionet moderne të PostgreSQL, parametri checkpoint_segments zëvendësohet me parametra min_wal_size и max_wal_size.

Nënsistemi tjetër është shkrimtari i sfondit − background writer. Çfarë po bën ai? Ajo funksionon vazhdimisht në një lak të pafund. Ai skanon faqet në bufera të përbashkëta dhe lan faqet e pista që gjen në disk. Në këtë mënyrë, ai ndihmon kontrolluesin të bëjë më pak punë gjatë pikës së kontrollit.

Për çfarë tjetër i nevojitet? Ai parashikon nevojën për faqe të pastra në bufera të përbashkëta nëse ato kërkohen papritur (në sasi të mëdha dhe menjëherë) për të akomoduar të dhëna. Supozoni se u krijua një situatë kur kërkesa kërkonte faqe të pastra dhe ato janë tashmë në bufera të përbashkëta. Postgres backend ai thjesht i merr dhe i përdor, nuk duhet të pastrojë asgjë vetë. Por nëse befas nuk ka faqe të tilla, backend ndërpret punën dhe fillon të kërkojë faqe për t'i hedhur ato në disk dhe për t'i marrë ato për nevojat e veta - gjë që ndikon negativisht në kohën e kërkesës aktualisht në ekzekutim. Nëse shihni që keni një parametër maxwritten_clean i madh, kjo do të thotë që shkrimtari i sfondit nuk po e bën punën e tij dhe ju duhet të rritni parametrat bgwriter_lru_maxpages, në mënyrë që ai të bëjë më shumë punë në një cikël, të pastrojë më shumë faqe.

Dhe një tregues tjetër shumë i dobishëm është buffers_backend_fsync. Backend-et nuk sinkronizohen sepse janë të ngadalta. Ata kalojnë fsync deri në pikën e kontrollit të rafte IO. Pika e kontrollit ka radhën e vet, ai përpunon periodikisht fsync dhe sinkronizon faqet në memorie me skedarët në disk. Nëse radha e pikave të kontrollit është e madhe dhe e plotë, atëherë backend-i detyrohet të bëjë vetë fsync dhe kjo ngadalëson backend-in, pra klienti do të marrë një përgjigje më vonë se sa mund. Nëse shihni që e keni këtë vlerë më të madhe se zero, atëherë ky është tashmë një problem dhe duhet t'i kushtoni vëmendje cilësimeve të shkrimtarit të sfondit dhe gjithashtu të vlerësoni performancën e nënsistemit të diskut.

Warning: _Teksti i mëposhtëm përshkruan pamjet statistikore të lidhura me përsëritjen. Shumica e emrave të pamjeve dhe funksioneve janë riemërtuar në Postgres 10. Thelbi i riemërtimeve ishte zëvendësimi xlog mbi wal и location mbi lsn në emrat e funksioneve/shikimeve etj. Shembull i veçantë, funksion pg_xlog_location_diff() u riemërua në pg_wal_lsn_diff()._

Edhe këtu kemi shumë. Por ne kemi nevojë vetëm për artikuj që lidhen me vendndodhjen.

Nëse shohim që të gjitha vlerat janë të barabarta, atëherë ky është një opsion ideal dhe kopja nuk mbetet pas mjeshtrit.

Ky pozicion heksadecimal këtu është pozicioni në regjistrin e transaksioneve. Ai vazhdimisht rritet nëse ka ndonjë aktivitet në bazën e të dhënave: fut, fshin, etj.

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

Nëse këto gjëra janë të ndryshme, atëherë ka një lloj vonese. Lag është vonesa midis replikës dhe masterit, d.m.th. të dhënat ndryshojnë midis serverëve.

Ka tre arsye për vonesën:

Është nënsistemi i diskut që nuk mund të trajtojë sinkronizimin e skedarëve.
Këto janë gabime të mundshme të rrjetit, ose mbingarkesa e rrjetit, kur të dhënat nuk kanë kohë për të arritur në kopje dhe nuk mund ta riprodhojnë atë.
Dhe procesori. Procesori është një rast shumë i rrallë. Dhe e kam parë këtë dy ose tre herë, por edhe kjo mund të ndodhë.

Dhe këtu janë tre pyetje që na lejojnë të përdorim statistika. Ne mund të vlerësojmë se sa është regjistruar në regjistrin tonë të transaksioneve. Ekziston një funksion i tillë pg_xlog_location_diff dhe ne mund të vlerësojmë vonesën e replikimit në bajt dhe sekonda. Ne gjithashtu përdorim vlerën nga kjo pamje (VIEWs) për këtë.

Shenim: _Në vend të pg_xlog_locationFunksioni diff() mund të përdorë operatorin e zbritjes dhe të zbresë një vend nga një tjetër. Të rehatshme.

Me një vonesë, e cila është në sekonda, ka një moment. Nëse nuk ka aktivitet në master, transaksioni ka qenë aty rreth 15 minuta më parë dhe nuk ka asnjë aktivitet, dhe nëse shikojmë këtë vonesë në kopje, do të shohim një vonesë prej 15 minutash. Kjo vlen të kujtohet. Dhe kjo mund të çojë në një hutim kur e shikoni këtë vonesë.

Pg_stat_all_tables është një tjetër pamje e dobishme. Ai tregon statistikat në tabela. Kur kemi tabela në bazën e të dhënave, ka ndonjë aktivitet me të, disa veprime, ne mund ta marrim këtë informacion nga kjo pamje.

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

Gjëja e parë që mund të shikojmë është skanimet vijuese të tabelës. Vetë numri pas këtyre pasazheve nuk është domosdoshmërisht i keq dhe nuk tregon se duhet të bëjmë diçka tashmë.

Sidoqoftë, ekziston një metrikë e dytë - seq_tup_read. Ky është numri i rreshtave të kthyer nga skanimi vijues. Nëse numri mesatar i kalon 1, 000, 10, 000, atëherë ky është tashmë një tregues që mund t'ju duhet të ndërtoni një indeks diku në mënyrë që akseset të jenë sipas indeksit, ose është e mundur të optimizoni pyetjet që përdorin skanime të tilla vijuese në mënyrë që kjo nuk ndodh, ishte.

Një shembull i thjeshtë - le të themi se një kërkesë me një OFFSET dhe LIMIT të madh ia vlen. Për shembull, 100 rreshta në një tabelë skanohen dhe pas kësaj merren 000 rreshtat e kërkuar dhe rreshtat e mëparshëm të skanuar hidhen. Ky është gjithashtu një rast i keq. Dhe kërkesa të tilla duhet të optimizohen. Dhe këtu është një pyetje kaq e thjeshtë SQL në të cilën mund ta shihni dhe të vlerësoni numrat e marrë.

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

Madhësitë e tabelave mund të merren gjithashtu duke përdorur këtë tabelë dhe duke përdorur funksione shtesë pg_total_relation_size(), pg_relation_size().

Në përgjithësi, ka metakomandime dt и di, të cilin mund ta përdorni në PSQL dhe gjithashtu shihni madhësitë e tabelës dhe indeksit.

Sidoqoftë, përdorimi i funksioneve na ndihmon të shohim madhësitë e tabelave, madje duke marrë parasysh indekset, ose pa marrë parasysh indekset, dhe tashmë të bëjmë disa vlerësime bazuar në rritjen e bazës së të dhënave, d.m.th se si po rritet, me çfarë intensiteti, dhe nxirrni disa përfundime rreth optimizimit të përmasave.

Aktivitet regjistrimi. Çfarë është një regjistrim? Le të shohim operacionin UPDATE – funksionimi i përditësimit të rreshtave në një tabelë. Në fakt, përditësimi është dy operacione (ose edhe më shumë). Kjo është duke futur një version të ri të rreshtit dhe duke shënuar versionin e vjetër të rreshtit si të vjetëruar. Më pas, autovakuumi do të vijë dhe do të pastrojë këto versione të vjetruara të linjave, duke e shënuar këtë vend si të disponueshëm për ripërdorim.

Gjithashtu, përditësimi nuk ka të bëjë vetëm me përditësimin e një tabele. Është ende një përditësim i indeksit. Nëse keni shumë indekse në tabelë, atëherë me përditësimin, të gjitha indekset në të cilat marrin pjesë fushat e përditësuara në pyetje do të duhet gjithashtu të përditësohen. Këto indekse do të kenë gjithashtu versione të rreshtave të vjetëruara që do të duhet të pastrohen.

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

Dhe për shkak të dizajnit të tij të ri, UPDATE është një operacion me peshë të rëndë. Por ato mund të bëhen më të lehta. Hani hot updates. Ato u shfaqën në versionin 8.3 të PostgreSQL. Dhe çfarë është kjo? Ky është një përditësim i lehtë që nuk shkakton rindërtim të indekseve. Kjo do të thotë, ne azhurnuam rekordin, por vetëm rekordi në faqe (i cili i përket tabelës) u përditësua, dhe indekset ende tregojnë të njëjtin rekord në faqe. Ka pak një logjikë kaq interesante të punës, kur vjen një vakum, atëherë i ka këto zinxhirë hot rindërtohet dhe gjithçka vazhdon të funksionojë pa përditësuar indekset, dhe gjithçka ndodh me më pak humbje burimesh.

Dhe kur ju n_tup_hot_upd i madh, është shumë i mirë. Kjo do të thotë që përditësimet e lehta mbizotërojnë dhe kjo është më e lirë për ne për sa i përket burimeve dhe gjithçka është në rregull.

ALTER TABLE table_name SET (fillfactor = 70);

Si të rritet vëllimi hot updateov? Ne mund të përdorim fillfactor. Përcakton madhësinë e hapësirës së lirë të rezervuar kur plotëson një faqe në një tabelë duke përdorur INSERT. Kur futjet shkojnë në tabelë, ato mbushin plotësisht faqen, nuk lënë hapësirë boshe në të. Pastaj theksohet një faqe e re. Të dhënat plotësohen përsëri. Dhe kjo është sjellja e paracaktuar, mbushje = 100%.

Mund ta vendosim faktorin mbushës në 70%. Domethënë, me inserte, u nda një faqe e re, por u plotësua vetëm 70% e faqes. Dhe ne kemi 30% rezervë. Kur duhet të bëni një përditësim, me shumë mundësi do të ndodhë në të njëjtën faqe dhe versioni i ri i rreshtit do të përshtatet në të njëjtën faqe. Dhe hot_update do të bëhet. Kjo e bën më të lehtë shkrimin në tabela.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Radha e autovakumit. Autovacuum është një nënsistem për të cilin ka shumë pak statistika në PostgreSQL. Ne mund të shohim vetëm në tabelat në pg_stat_activity sa vakum kemi në këtë moment. Megjithatë, është shumë e vështirë të kuptosh se sa tavolina janë në radhë menjëherë.

Shenim: _Që nga Postgres 10, situata me gjurmimin e vakumit të vakumit është përmirësuar shumë - është shfaqur pamja pg_stat_progressvakum, i cili thjeshton shumë çështjen e monitorimit të autovakumit.

Ne mund ta përdorim këtë pyetje të thjeshtuar. Dhe ne mund të shohim se kur do të duhet të bëhet vakuumi. Por si dhe kur duhet të fillojë vakuumi? Këto janë versionet e trashëguara të linjave për të cilat po flisja më herët. Përditësimi ndodhi, një version i ri i linjës u fut. Është shfaqur një version i vjetëruar i vargut. Ne tavoline pg_stat_user_tables ekziston një parametër i tillë n_dead_tup. Ai tregon numrin e rreshtave "të vdekur". Dhe sapo numri i rreshtave të vdekur të jetë bërë më shumë se një prag i caktuar, një autovakum do të vijë në tryezë.

Dhe si llogaritet ky prag? Kjo është një përqindje shumë specifike e numrit të përgjithshëm të rreshtave në tabelë. Ka një parametër autovacuum_vacuum_scale_factor. Ajo përcakton përqindjen. Le të themi 10% + ka një prag bazë shtesë prej 50 rreshtash. Dhe çfarë ndodh? Kur kemi më shumë rreshta të vdekur se "10% + 50" të të gjitha rreshtave në tabelë, atëherë e vendosim tabelën në autovakum.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Megjithatë, ka një pikë. Pragjet bazë për parametrat av_base_thresh и av_scale_factor mund të caktohet individualisht. Dhe, në përputhje me rrethanat, pragu nuk do të jetë global, por individual për tryezën. Prandaj, për të llogaritur, atje duhet të përdorni truket dhe truket. Dhe nëse jeni të interesuar, mund të shikoni përvojën e kolegëve tanë nga Avito (lidhja në rrëshqitje është e pavlefshme dhe është përditësuar në tekst).

Ata shkruanin për shtojca muninqë i merr parasysh këto gjëra. Ka një mbulesë këmbësh në dy çarçafë. Por ai e konsideron saktë dhe mjaft efektivisht na lejon të vlerësojmë se ku kemi nevojë për shumë vakum për tavolina, ku ka pak.

Çfarë mund të bëjmë për këtë? Nëse kemi një radhë të gjatë dhe autovakuumi nuk e përballon dot, atëherë mund të rrisim numrin e punonjësve të vakumit, ose thjesht ta bëjmë vakumin më agresiv.në mënyrë që të ndizet më herët, përpunon tabelën në copa të vogla. Dhe kështu radha do të ulet. - Gjëja kryesore këtu është të monitoroni ngarkesën në disqe, sepse. Gjëja e vakumit nuk është falas, megjithëse me ardhjen e pajisjeve SSD / NVMe, problemi është bërë më pak i dukshëm.

pg_stat_all_indexes është statistika mbi indekset. Ajo nuk është e madhe. Dhe ne mund të marrim informacion mbi përdorimin e indekseve prej tij. Dhe për shembull, ne mund të përcaktojmë se cilat indekse kemi shtesë.

Siç thashë tashmë, përditësimi nuk është vetëm përditësimi i tabelave, por gjithashtu përditësimi i indekseve. Prandaj, nëse kemi shumë indekse në tabelë, atëherë kur përditësoni rreshtat në tabelë, indekset e fushave të indeksuara gjithashtu duhet të përditësohen, dhe nëse kemi indekse të papërdorura për të cilat nuk ka skanime të indeksit, atëherë ato varen si çakëll. Dhe ne duhet të shpëtojmë prej tyre. Për këtë na duhet një fushë idx_scan. Ne thjesht shikojmë numrin e skanimeve të indeksit. Nëse indekset kanë skanime zero gjatë një periudhe relativisht të gjatë të ruajtjes së statistikave (të paktën 2-3 javë), atëherë ka shumë të ngjarë që këto janë indekse të këqija, ne duhet t'i heqim qafe ato.

Shenim: Kur kërkoni për indekse të papërdorura në rastin e grupeve të riprodhimit të transmetimit, duhet të kontrolloni të gjitha nyjet e grupimit, sepse statistikat nuk janë globale, dhe nëse indeksi nuk përdoret në master, atëherë mund të përdoret në kopje (nëse ka një ngarkesë).

Dy lidhje:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Këta janë shembuj më të avancuar të pyetjeve se si të kërkoni indekset e papërdorura.

Lidhja e dytë është një pyetje mjaft interesante. Ka një logjikë shumë jo të parëndësishme në të. Unë e rekomandoj atë për rishikim.

Çfarë tjetër duhet të përmblidhet me indekse?

Indekset e papërdorura janë të këqija.
Ata zënë hapësirë.
Ngadalësoni operacionet e përditësimit.
Punë shtesë për vakum.

Nëse heqim indekset e papërdorura, atëherë vetëm do ta përmirësojmë bazën e të dhënave.

Prezantimi i radhës është pg_stat_activity. Ky është një analog i shërbimeve ps, vetëm në PostgreSQL. Nëse ps'Om ju shikoni proceset në sistemin operativ, atëherë pg_stat_activity Do t'ju tregojë aktivitetin brenda PostgreSQL.

Çfarë mund të marrim prej andej?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Ne mund të shohim aktivitetin e përgjithshëm që po ndodh në bazën e të dhënave. Ne mund të bëjmë një vendosje të re. Gjithçka shpërtheu atje, lidhjet e reja nuk pranohen, gabimet po derdhen në aplikacion.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Mund të ekzekutojmë një pyetje si kjo dhe të shohim përqindjen totale të lidhjeve në lidhje me kufirin maksimal të lidhjes dhe të shohim se kush kemi më shumë lidhje. Dhe në këtë rast, ne e shohim atë përdorues cron_role hapi 508 lidhje. Dhe diçka i ndodhi atij. Ju duhet të merreni me të dhe të shihni. Dhe është mjaft e mundur që ky është një lloj numri anormal i lidhjeve.

Nëse kemi një ngarkesë pune OLTP, pyetjet duhet të jenë të shpejta, shumë të shpejta dhe nuk duhet të ketë pyetje të gjata. Sidoqoftë, nëse lindin pyetje të gjata, atëherë në afat të shkurtër nuk ka asgjë për t'u shqetësuar, por në terma afatgjatë, pyetjet e gjata dëmtojnë bazën e të dhënave, ato rrisin efektin e fryrjes së tabelave kur ndodh fragmentimi i tabelave. Të dyja pyetjet e fryra dhe të gjata duhet të asgjësohen.

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

Ju lutemi vini re: me një kërkesë të tillë, ne mund të përcaktojmë kërkesa dhe transaksione të gjata. Ne përdorim funksionin clock_timestamp() për të përcaktuar kohën e punës. Kërkesat e gjata që gjetëm, mund t'i kujtojmë, t'i zbatojmë explain, shikoni planet dhe optimizoni disi. Ne realizojmë kërkesat e gjata aktuale dhe jetojmë.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Transaksionet e këqija janë transaksione në gjendje të papunë në transaksion dhe në gjendje të papunë në transaksion (të ndërprerë).

Çfarë do të thotë? Transaksionet kanë shumë gjendje. Dhe një nga këto shtete mund të marrë në çdo kohë. Ekziston një fushë për të përcaktuar gjendjet state në këtë këndvështrim. Dhe ne e përdorim atë për të përcaktuar gjendjen.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Dhe, siç thashë më lart, këto dy shtete boshe në transaksion dhe boshe në transaksion (të ndërprerë) janë të këqija. Cfare eshte? Kjo është kur aplikacioni hapi një transaksion, bëri disa veprime dhe vazhdoi punën e tij. Transaksioni mbetet i hapur. Varet, asgjë nuk ndodh në të, kërkon një lidhje, kyçet në rreshtat e ndryshuar dhe potencialisht rrit ende fryrjen e tabelave të tjera, për shkak të arkitekturës së motorit transaksional Postrges. Dhe transaksione të tilla duhen qëlluar, sepse janë të dëmshme në përgjithësi, në çdo rast.

Nëse shihni se keni më shumë se 5-10-20 prej tyre në bazën e të dhënave, atëherë duhet të shqetësoheni dhe të filloni të bëni diçka me ta.

Këtu përdorim edhe për kohën e llogaritjes clock_timestamp(). Ne realizojmë transaksione, ne optimizojmë aplikacionin.

Siç thashë më lart, bllokimet janë kur dy ose më shumë transaksione konkurrojnë për një ose një grup burimesh. Për këtë kemi një fushë waiting me vlerë boolean true ose false.

E vërtetë - kjo do të thotë që procesi është duke pritur, diçka duhet bërë. Kur një proces është në pritje, atëherë klienti që ka iniciuar procesin është gjithashtu në pritje. Klienti në shfletues ulet dhe gjithashtu pret.

Warning: _Duke filluar nga Postgres 9.6, fusha waiting hequr dhe zëvendësuar nga dy fusha të tjera informative wait_event_type и wait_event._

Çfarë duhet të bëni? Nëse e shihni të vërtetën për një kohë të gjatë, do të thotë që duhet të hiqni qafe kërkesa të tilla. Ne thjesht rrëzojmë transaksione të tilla. Ne u shkruajmë zhvilluesve që ata duhet të optimizojnë disi në mënyrë që të mos ketë garë për burime. Dhe më pas zhvilluesit optimizojnë aplikacionin në mënyrë që kjo të mos ndodhë.

Dhe një rast ekstrem, por potencialisht jo fatal është shfaqja e ngërçeve. Dy transaksione përditësuan dy burime, më pas iu qasën sërish, këtë herë në burime të kundërta. Në këtë rast, PostgreSQL vret vetë transaksionin në mënyrë që një tjetër të mund të vazhdojë të punojë. Kjo është një situatë qorre dhe ajo nuk mund ta kuptojë vetë. Prandaj, PostgreSQL është i detyruar të marrë masa ekstreme.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Dhe këtu janë dy pyetje që ju lejojnë të gjurmoni bllokimin. Ne përdorim pamjen pg_locks, e cila ju lejon të gjurmoni flokët e rëndë.

Dhe lidhja e parë është vetë teksti i kërkesës. Është mjaft e gjatë.

Dhe lidhja e dytë është një artikull mbi flokët. Është e dobishme për të lexuar, është shumë interesante.

Pra, çfarë shohim? Ne shohim dy kërkesa. Transaksioni me ALTER TABLE është një transaksion bllokues. Filloi, por nuk mbaroi dhe aplikacioni që postoi këtë transaksion po bën gjëra të tjera diku. Dhe kërkesa e dytë është përditësimi. Ai pret që tabela e ndryshimit të përfundojë përpara se të vazhdojë punën e saj.

Kështu mund të zbulojmë se kush kë ka mbyllur, kush kë po mban dhe mund ta trajtojmë këtë më tej.

Moduli tjetër është pg_stat_statements. Siç thashë, është një modul. Për ta përdorur atë, duhet të ngarkoni bibliotekën e saj në konfigurim, të rinisni PostgreSQL, të instaloni modulin (me një komandë) dhe më pas do të kemi një pamje të re.

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

Çfarë mund të marrim prej andej? Nëse flasim për gjëra të thjeshta, mund të marrim kohën mesatare të ekzekutimit të pyetjes. Koha po rritet, që do të thotë se PostgreSQL po përgjigjet ngadalë dhe ne duhet të bëjmë diçka.

Ne mund të shohim transaksionet më aktive të shkrimit në bazën e të dhënave që ndryshojnë të dhënat në buferët e përbashkët. Shihni kush përditëson ose fshin të dhënat atje.

Dhe ne thjesht mund të shikojmë statistika të ndryshme për këto pyetje.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

Ne pg_stat_statements përdoret për të ndërtuar raporte. Ne rivendosim statistikat një herë në ditë. Le ta grumbullojmë. Para se të rivendosim statistikat herën tjetër, ne ndërtojmë një raport. Këtu është një lidhje me raportin. Mund ta shikoni.

Cfare po bejme? Ne llogarisim statistikat e përgjithshme për të gjitha kërkesat. Më pas, për çdo pyetje, ne llogarisim kontributin e tij individual në këtë statistikë të përgjithshme.

Dhe çfarë mund të shohim? Ne mund të shohim kohën totale të ekzekutimit të të gjitha kërkesave të një lloji të caktuar në sfondin e të gjitha kërkesave të tjera. Ne mund të shohim përdorimin e CPU dhe I/O në lidhje me pamjen e përgjithshme. Dhe tashmë për të optimizuar këto kërkesa. Ne po ndërtojmë pyetjet kryesore bazuar në këtë raport dhe tashmë po gjejmë ushqim për të menduar se çfarë të optimizojmë.

Çfarë kemi lënë në prapaskenë? Kanë mbetur edhe disa parashtresa që nuk i kam marrë në konsideratë sepse koha është e kufizuar.

Ka pgstattuple është gjithashtu një modul shtesë nga paketa standarde e kontributeve. Kjo ju lejon të vlerësoni bloat tavolina, të ashtuquajturat. fragmentimi i tabelës. Dhe nëse fragmentimi është i madh, duhet ta hiqni atë, të përdorni mjete të ndryshme. Dhe funksioni pgstattuple punon për një kohë të gjatë. Dhe sa më shumë tabela, aq më gjatë do të funksionojë.

Kontributi tjetër është pg_buffercache. Kjo ju lejon të inspektoni buferët e përbashkët: sa intensivisht dhe për cilat tabela përdoren faqet e buferit. Dhe thjesht ju lejon të shikoni në buferat e përbashkëta dhe të vlerësoni se çfarë po ndodh atje.

Moduli tjetër është pgfincore. Kjo ju lejon të kryeni operacione të tabelave të nivelit të ulët përmes një thirrjeje sistemi mincore(), d.m.th. ju lejon të ngarkoni tabelën në buferë të përbashkët, ose ta shkarkoni atë. Dhe lejon, ndër të tjera, të inspektoni cache-in e faqeve të sistemit operativ, domethënë sa zë tabela në cache-in e faqeve, në buferat e përbashkëta, dhe thjesht ju lejon të vlerësoni ngarkesën në tabelë.

Moduli tjetër është pg_stat_kcache. Ai gjithashtu përdor një thirrje sistemi getrusage(). Dhe e ekzekuton atë para dhe pas ekzekutimit të kërkesës. Dhe në statistikat që rezultojnë, na lejon të vlerësojmë se sa ka shpenzuar kërkesa jonë në I/O të diskut, d.m.th., operacionet me sistemin e skedarëve dhe shikon përdorimin e procesorit. Megjithatë, moduli është i ri (kollë kollë) dhe për funksionimin e tij kërkon PostgreSQL 9.4 dhe pg_stat_statements, të cilat i përmenda më herët.

Aftësia për të përdorur statistikat është e dobishme. Ju nuk keni nevojë për softuer të palëve të treta. Mund të shikoni, shihni, bëni diçka, performoni.
Përdorimi i statistikave është i lehtë, është i thjeshtë SQL. Ju mblodhët një kërkesë, e përpiluat, e dërguat, e shikonit.
Statistikat ndihmojnë për t'iu përgjigjur pyetjeve. Nëse keni pyetje, i drejtoheni statistikave - shikoni, nxirrni përfundime, analizoni rezultatet.
Dhe eksperimentoni. Shumë kërkesa, shumë të dhëna. Ju gjithmonë mund të optimizoni disa pyetje ekzistuese. Ju mund të bëni versionin tuaj të kërkesës që ju përshtatet më mirë se origjinali dhe ta përdorni atë.