podpora grafovych dotazu v Postgresu 19

[Pavel Stehule]

Ahoj

tak jestli to tam zůstane, tak Postgres mít podporou SQL/PGQ. Sám nevím, co si o tom mám myslet. Tohle má k relačním databázím hodně daleko.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c

Je fakt, že už jsem viděl v Postgresu databáze, kdy data byly serializované grafy, a de facto se hledalo něco v grafech. Bylo to dost pomalé. Možná s "nativní" podporou by to mohlo být rychlejsí.

Pavel

[Josef Šimánek]

po 16. 3. 2026 v 11:15 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:

>
> Ahoj
>
> tak jestli to tam zůstane, tak Postgres mít podporou SQL/PGQ. Sám nevím, co si o tom mám myslet. Tohle má k relačním databázím hodně daleko.

No když se to vezme kolem a kolem, tak to vypadá jako alternativní
syntax pro relační data generující JOIN + (volitelně) UNION.

> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c
>
> Je fakt, že už jsem viděl v Postgresu databáze, kdy data byly serializované grafy, a de facto se hledalo něco v grafech. Bylo to dost pomalé. Možná s "nativní" podporou by to mohlo být rychlejsí.

Vypadá to, že ten dotaz je stejně rychlej jako ta JOIN + UNION
varianta. Spíš jsem zpozorněl, že v poslední době do Postgresu
začínají přibývat v relativně krátkém čase velké patche dost
rozšiřující SQL parser či implementující vlastní string parser.
Například nedávno ten pg_plan_advice, teď tohle.

Nevím jaké má kdo zkušenosti s psaním a hlavně udržováním většího
parseru, ale za mě je to peklo a pro lidi naprosto nepřirozený úkol.
Naopak AI a programovací LLM modely v tomhle dost excelují. Možná jsme
svědky nějaké vlny nových funkcí, jenž si uživatelé dlouho přejí, ale
nikdo neměl odvahu bojovat s tím parsováním na kterém je SQL založené
a je bránou do databáze.

Pokud jsem to správně pochopil, tak složitost změn v SQL parseru často
vedla ke kompromisu nad syntaxí. Například CREATE INDEX, REINDEX INDEX
and DROP INDEX a podobné skupiny příkazů jsou dost nekonzistentní v
přebírání parametrů. Také parametry tuším nejsou možné momentálně
složit z více slov viz \h VACUUM. Možná se blýská na lepší časy.
:pray: Nebo jsem úplně mimo a je v tom jiný důvod?

> 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/CAFj8pRCkvCn54-9Dg%2BPz%3Dpge%2BzDgxjA3_edqnjRLjQXM3yqx-A%40mail.gmail.com.

[Pavel Stehule]

po 16. 3. 2026 v 12:27 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

po 16. 3. 2026 v 11:15 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:
>
> Ahoj
>
> tak jestli to tam zůstane, tak Postgres mít podporou SQL/PGQ. Sám nevím, co si o tom mám myslet. Tohle má k relačním databázím hodně daleko.

No když se to vezme kolem a kolem, tak to vypadá jako alternativní
syntax pro relační data generující JOIN + (volitelně) UNION.

> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c
>
> Je fakt, že už jsem viděl v Postgresu databáze, kdy data byly serializované grafy, a de facto se hledalo něco v grafech. Bylo to dost pomalé. Možná s "nativní" podporou by to mohlo být rychlejsí.

Vypadá to, že ten dotaz je stejně rychlej jako ta JOIN + UNION
varianta. Spíš jsem zpozorněl, že v poslední době do Postgresu
začínají přibývat v relativně krátkém čase velké patche dost
rozšiřující SQL parser či implementující vlastní string parser.
Například nedávno ten pg_plan_advice, teď tohle.

Nevím jaké má kdo zkušenosti s psaním a hlavně udržováním většího
parseru, ale za mě je to peklo a pro lidi naprosto nepřirozený úkol.
Naopak AI a programovací LLM modely v tomhle dost excelují. Možná jsme
svědky nějaké vlny nových funkcí, jenž si uživatelé dlouho přejí, ale
nikdo neměl odvahu bojovat s tím parsováním na kterém je SQL založené
a je bránou do databáze.

Hele toho bych se nebál - V Postgresu se parser generuje z gramatiky, a bison (yacc) je roky prověřený generátor parserů. 

Navíc pg_plan_advice nemá s parserem skoro nic společného. Přidat příkaz do gramatiky není moc obtížný. Horší je, když se musí fixnout kolize, pokud je bizon najde. Tam aspoň já musím hodně přemyklíkovat myšlení - je to takový matfyzácký rekurzivní programování, případně gamesa s prioritama. Ale jakmile je to jednou zapsané, a bezkolizní, tak veškerou práci za tebe udělá bison - bez ohledu na velikost.

To, že zmíněné patche skončí v 19 je spíš náhoda. Prototyp SQL/PGQ napsal Peter a podle mne spíš aby se seznámil s konceptem, který také schvaloval někdy kolem roku 2023. A na pg_plan_advice teď měl Robert Haas víc času, jelikož v 18 dokončil inkrementální backup.

 

Pokud jsem to správně pochopil, tak složitost změn v SQL parseru často
vedla ke kompromisu nad syntaxí. Například CREATE INDEX, REINDEX INDEX
and DROP INDEX a podobné skupiny příkazů jsou dost nekonzistentní v
přebírání parametrů. Také parametry tuším nejsou možné momentálně
složit z více slov viz \h VACUUM. Možná se blýská na lepší časy.
:pray: Nebo jsem úplně mimo a je v tom jiný důvod?

Zrovna u zmíněných příkazů je gramatika docela jednoduchá a bezkolizní. Tam je spíš historická zátěž. Historicky u SQL bylo nutné dodržet pořadí jednotlivých klauzulí.

VACUUM FREEZE VERBOSE tab

a nefunguje VACUUM VERBOSE FREEZE tab

Implementačně by nebyl problém to napsat tak, že by options u VACUUA mohly být v libovolném pořadí. Nicméně historicky to nebylo - a z nějakých důvodů (ale ne technických) se to nezměnilo - mám pocit, že tím hlavním důvodem  byl jakási konzistence s SQL, kdy se respektuje pořadí. Jak se ale postupně přidávaly další parametry do VACUUA, tak dodržování pořadí byl čím dál tím víc ergonomický problém (nikoliv technický - v gramatice je to jedno), tak se tam přidala syntaxe

VACUUM (options [, ...]) ...

kde uvnitř závorek nezáleží na pořadí.

v bledě modrém totéž platí pro EXPLAIN 

Je možné, že si to nevybavuju správně - co jsem našel v gitu, tak je to minimálně 11 let stará záležitost - spíš víc https://github.com/postgres/postgres/commit/0d831389749a3baaced7b984205b9894a82444b9

Letos se trochu nakouslo téma přejít na jiný generátor parserů - případně si napsat vlastní. Což je téma, které se objevuje opakovaně posledních 15 let. bison má jednu velkou nevýhodu - neumí vygenerovat dynamicky rozšiřitelnou gramatiku. V extenzi se nedá rozšířit syntax, což by se občas hodilo. Pokud by se tohle umělo, pak by se např. SQL/PGQ nebo SQL/JSON mohl kompletně řešit jako extenze. Mně by se to pro Orafce hodilo taky. Ale to už mi přijde jako velká utopie.

Pavel

> 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/CAFj8pRCkvCn54-9Dg%2BPz%3Dpge%2BzDgxjA3_edqnjRLjQXM3yqx-A%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/CAFp7Qwq%2BsQGh2Kboona12rjJQX9b%3DWUL-LYOSztEvLQMRLazjQ%40mail.gmail.com.

[Pavel Stehule]

po 16. 3. 2026 v 13:12 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

po 16. 3. 2026 v 12:27 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

po 16. 3. 2026 v 11:15 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:
>
> Ahoj
>
> tak jestli to tam zůstane, tak Postgres mít podporou SQL/PGQ. Sám nevím, co si o tom mám myslet. Tohle má k relačním databázím hodně daleko.

No když se to vezme kolem a kolem, tak to vypadá jako alternativní
syntax pro relační data generující JOIN + (volitelně) UNION.

> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=2f094e7ac691abc9d2fe0f4dcf0feac4a6ce1d9c
>
> Je fakt, že už jsem viděl v Postgresu databáze, kdy data byly serializované grafy, a de facto se hledalo něco v grafech. Bylo to dost pomalé. Možná s "nativní" podporou by to mohlo být rychlejsí.

Vypadá to, že ten dotaz je stejně rychlej jako ta JOIN + UNION
varianta. Spíš jsem zpozorněl, že v poslední době do Postgresu
začínají přibývat v relativně krátkém čase velké patche dost
rozšiřující SQL parser či implementující vlastní string parser.
Například nedávno ten pg_plan_advice, teď tohle.

Nevím jaké má kdo zkušenosti s psaním a hlavně udržováním většího
parseru, ale za mě je to peklo a pro lidi naprosto nepřirozený úkol.
Naopak AI a programovací LLM modely v tomhle dost excelují. Možná jsme
svědky nějaké vlny nových funkcí, jenž si uživatelé dlouho přejí, ale
nikdo neměl odvahu bojovat s tím parsováním na kterém je SQL založené
a je bránou do databáze.

Hele toho bych se nebál - V Postgresu se parser generuje z gramatiky, a bison (yacc) je roky prověřený generátor parserů. 

Navíc pg_plan_advice nemá s parserem skoro nic společného. Přidat příkaz do gramatiky není moc obtížný. Horší je, když se musí fixnout kolize, pokud je bizon najde. Tam aspoň já musím hodně přemyklíkovat myšlení - je to takový matfyzácký rekurzivní programování, případně gamesa s prioritama. Ale jakmile je to jednou zapsané, a bezkolizní, tak veškerou práci za tebe udělá bison - bez ohledu na velikost.

To, že zmíněné patche skončí v 19 je spíš náhoda. Prototyp SQL/PGQ napsal Peter a podle mne spíš aby se seznámil s konceptem, který také schvaloval někdy kolem roku 2023. A na pg_plan_advice teď měl Robert Haas víc času, jelikož v 18 dokončil inkrementální backup.

oprava - inkrementální backup je v 17