sikovna aplikace - online EXPLAIN

[Pavel Stehule]

Ahoj

viz https://github.com/mickamy/sql-tap

Pavel

[Josef Šimánek]

po 16. 2. 2026 v 10:56 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:
>
> Ahoj
>
> viz https://github.com/mickamy/sql-tap

Vypadá to hezky, ale jestli jsem to správně pochopili, tak to skenuje
provoz klienta za běhu a je třeba toho klienta připojit na ten sql-tap
server, který funguje jako proxy do Postgresu. To z toho bohužel
nedělá zrovna jednoduchý nástroj, co lze rychle a bezpečně zkusit na
produkci.

> Pavel
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRD%3D6SUP%2B_6ifOcSy-mx%3DATYOr%2BOFm_h-Cs1pL6hAFJtdA%40mail.gmail.com.

[Pavel Stehule]

po 16. 2. 2026 v 11:38 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

po 16. 2. 2026 v 10:56 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:
>
> Ahoj
>
> viz https://github.com/mickamy/sql-tap

Vypadá to hezky, ale jestli jsem to správně pochopili, tak to skenuje
provoz klienta za běhu a je třeba toho klienta připojit na ten sql-tap
server, který funguje jako proxy do Postgresu. To z toho bohužel
nedělá zrovna jednoduchý nástroj, co lze rychle a bezpečně zkusit na
produkci.

Autor ma na svem webu jeste variantu, kdy monitoring schoval do SQL driveru (pro GO).

Aplikaci tohoto typu moc neni - jeste si vybavuju, dneska uz letity, pgshark https://dalibo.github.io/pgshark/

Dokud Postgres tuhle funkcionalitu nebude poskytovat nativne, tak vzdy to bude nejakym zpusobem vachrlaty. A nativne ji nepodporuje (pres x pokusu)

kvuli izolaci session v procesech a kvuli handlovani signalu v procesech. Proste neni jednoduche si z aktivniho procesu vytahnout provadeci plan (z jineho procesu). 

Stavajici extenze funguji na principu ulozeni provadeciho planu do sdilene pameti, kde se da dohledat. Ale zase je to vachrlate - muze to zbytecne zabirat sdilenou pamet - a hodne sdilene pameti a zvysuje to rezii startu dotazu.

> Pavel
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRD%3D6SUP%2B_6ifOcSy-mx%3DATYOr%2BOFm_h-Cs1pL6hAFJtdA%40mail.gmail.com.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/CAFp7QwoQ-UQEtsETJX29B0oymtUfshCifrMzOFnUjpJRRLXUNA%40mail.gmail.com.

[Peter]

Skusil som pg-tap teraz na localhoste a celkom funguje. Procesy nemusia byt kolokovane s postgres backendom na tom istom hoste. Ma to daemon, ktory plni rolu proxy: pripoji sa na postgresovy port (5432) a dalsi port otvori (napr. 5433), na ktory sa pripoji SQL klient (psql). Ten daemon dalej otvori port pre sql-tap TUI klienta (default 9091), kde sa daju dotazy interaktivne prehliadat. Robi to priebezne nejake statistiky, vie to sortovat, vyhladavat, editovat query, kopirovat s argumentami, ...

Neviem ci ma ten daemon aj nejaku perzistenciu. By default po starte daemona alebo TUI klienta nevidim ziadnu historiu. Dokonca aj ked daemon zostane bezat a restartnem klienta, nevidim historiu. Po restarte daemona skonci TUI klient s error hlaskou a uz sa nepripoji => strati sa historia. Restart postgres backendu to prezije (daemon sa reconnectne a TUI si zachova historiu).

Ako lepsia server-side alternativa mi napada len auto_expain.

https://www.postgresql.org/docs/current/auto-explain.html

Velmi rad by som auto_explain preloadol na nasich produkciach - pre potreby riesenia buducich problemov, ale neviem aky to ma overhead, tak som si zatial netrufol. 

Dost ma na tom laka auto_explain.log_nested_statements - kedze vacsinu business logiky mame v ulozenych funkciach.

.pl.

[Pavel Stehule]

po 16. 2. 2026 v 13:29 odesílatel Peter <pgs...@gmail.com> napsal:

Skusil som pg-tap teraz na localhoste a celkom funguje. Procesy nemusia byt kolokovane s postgres backendom na tom istom hoste. Ma to daemon, ktory plni rolu proxy: pripoji sa na postgresovy port (5432) a dalsi port otvori (napr. 5433), na ktory sa pripoji SQL klient (psql). Ten daemon dalej otvori port pre sql-tap TUI klienta (default 9091), kde sa daju dotazy interaktivne prehliadat. Robi to priebezne nejake statistiky, vie to sortovat, vyhladavat, editovat query, kopirovat s argumentami, ...

Neviem ci ma ten daemon aj nejaku perzistenciu. By default po starte daemona alebo TUI klienta nevidim ziadnu historiu. Dokonca aj ked daemon zostane bezat a restartnem klienta, nevidim historiu. Po restarte daemona skonci TUI klient s error hlaskou a uz sa nepripoji => strati sa historia. Restart postgres backendu to prezije (daemon sa reconnectne a TUI si zachova historiu).

Ako lepsia server-side alternativa mi napada len auto_expain.

https://www.postgresql.org/docs/current/auto-explain.html

Velmi rad by som auto_explain preloadol na nasich produkciach - pre potreby riesenia buducich problemov, ale neviem aky to ma overhead, tak som si zatial netrufol. 

Dost ma na tom laka auto_explain.log_nested_statements - kedze vacsinu business logiky mame v ulozenych funkciach.

pro plany existuje https://github.com/pganalyze/pg_stat_plans

auto_explain bez ANALYZE ma minimalni rezii - kdyz se tam da rozumny prah, par desitek ms, tak by to melo byt uplne v pohode. Jde o to, abyste si logovanim nezabili IO.

Pred 13 roky jsme auto_explain meli jako default pro dotazy nad 50ms a nevzpominam si na problemy. Jen tech planu bylo tolik, ze pro analyzu musel Tomas Vondra napat vlastni aplikaci.

Jinak jestli pouzivate ulozene procedury, tak urcite si zapnete track_function - to ma temer nulovou rezii, a vystupy jsou neocenitelne

take muzete pouzit profiler https://github.com/bigsql/plprofiler nebo profiler v plpgsql_checku https://github.com/okbob/plpgsql_check

Pavel

 

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/8ddb75f7-1299-4348-8c7c-59e944d8786en%40googlegroups.com.

[Peter]

track_function: neviem ako je mozne, ze som si existenciu tohto nastavenia doteraz nevsimol (a to robim s postgresom od verzie 7.4) - velka vdaka!

auto_explain: skusim to postupne pretlacit do produkcii s velkym log_min_duration (>=1000); log_analyze a log_nested_statements by som zapinal on demand

plpgsql_check: uz 10 rokov sa to "chystam" pretlacit do ci/cd 0:-) mozno teraz sa mi to uz naozaj podari

musim este vymysliet, ako ignorovat false positives, ktore mame (temp. tables, ktore uz ale nemozem prerabat podla README)

plprofiler: pozriem, vdaka

pg_stat_plans: zatial necham na neskor - Experimental. May still change in incompatible ways without notice. Not (yet) recommended for production use.

.pl.

[Pavel Stehule]

po 16. 2. 2026 v 17:21 odesílatel Peter <pgs...@gmail.com> napsal:

track_function: neviem ako je mozne, ze som si existenciu tohto nastavenia doteraz nevsimol (a to robim s postgresom od verzie 7.4) - velka vdaka!

je to takova nenapadna funkce, ale uz se mi to parkrat u zakaznika hodne osvedcilo. Naprosto luxusne tam jsou videt pomale a casto volane funkce, nebo funkce volane extremne casto. 

A dost casto je bottleneck docela skryty - v auditni funkci nebo ve funkci, ktera realizuje vlastni implementaci pristupovych prav. Navic rezie je fakt +/- 0.

 

auto_explain: skusim to postupne pretlacit do produkcii s velkym log_min_duration (>=1000); log_analyze a log_nested_statements by som zapinal on demand

plpgsql_check: uz 10 rokov sa to "chystam" pretlacit do ci/cd 0:-) mozno teraz sa mi to uz naozaj podari

muzete pouzit PRAGMA https://github.com/okbob/plpgsql_check#temporary-tables

 

musim este vymysliet, ako ignorovat false positives, ktore mame (temp. tables, ktore uz ale nemozem prerabat podla README)

plprofiler: pozriem, vdaka

pg_stat_plans: zatial necham na neskor - Experimental. May still change in incompatible ways without notice. Not (yet) recommended for production use.

Cybertec o pg_stat_plans mluvi jako o pouzivane veci - je otazkou jestli jsem nasel aktualni repozitar - (ten link co jsem poslal je k verzi 2.0)

https://www.cybertec-postgresql.com/en/monitoring-query-plans-with-pgwatch-and-pg_stat_plans/

je to extenze, ktera uz existovala v https://github.com/2ndQuadrant/pg_stat_plans  

https://pgeoghegan.blogspot.com/2012/10/first-release-of-pgstatplans.html

K te hlasce  " Experimental. May still change in incompatible ways without notice." - v podstate to muze znamenat, ze se muze jeste ladit interface, coz ja u plpgsql_checku delam take (a bez takhle explicitniho upozorneni). Jen zmenim semantickou verzi. Kdyz jsem se podival na seznam issues, tak je to docela ciste. O tom projektu moc nevim, vyjma toho, ze existuje, ale kdyz se divam do historie commitu, tak v podstate prevzali kod ze 2nd quadrantu, fixli regresni testy pro 16-17, a napsali podporu pro 18tku.

https://resources.pganalyze.com/pganalyze_PGConf_EU_2025_pg_stat_plans.pdf

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/3c7a32b4-f4a7-4694-b674-6bf214faef09n%40googlegroups.com.