| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Henri GASC <henri(dot)gasc(at)airbus(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [SQL/PGQ] Custom executor node for VLE |
| Date: | 2026-07-21 15:10:18 |
| Message-ID: | kz3vyyrpub5kckq2wkw2i7we3fc6xpusxklv2z7hobc3v7ecad@yet4uyopjybz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-07-21 16:06:55 +0200, Henri GASC wrote:
> From what I understand, graph queries are rewritten into JOIN queries in order
> to use the complete machinery available for optimization.
> However, only single hop are currently allowed. While more complex queries are
> parsed, an error is raised by the executor if it encounter this situation.
> VLE are not allowed at all, and we are missing the capabilities to support
> TRAIL/SIMPLE/ACYCLIC syntax, as well as SHORTEST and other selective path
> search prefixes.
>
> My plan was to keep the query rewriting for fixed-depth, and switch to the
> custom executor in case of VLE, with VLE following the strategy from Henson
> Choi ([1]) (with the correct syntax for the queries).
>
> However, it seems a rather complex thing to keep with query rewriting,
FWIW, I continue to believe that choosing to implement something like PGQ in
the rewriter is architecturally wrong:
https://postgr.es/m/20240216192301.q2tf4bqjydymg3g2%40awork3.anarazel.de
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ZizhuanLiu X-MAN | 2026-07-21 15:13:32 | Re: support create index on virtual generated column. |
| Previous Message | Andres Freund | 2026-07-21 15:03:17 | Re: pg19b1: TRAP: failed Assert("pgstat_bktype_io_stats_valid(bktype_shstats, MyBackendType)") |