| From: | Henri GASC <henri(dot)gasc(at)airbus(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | [SQL/PGQ] Custom executor node for VLE |
| Date: | 2026-07-21 14:06:55 |
| Message-ID: | CAJyuuthCZ8yQuUAy_1d0DkxtdQ_aZcOX+7bcwagwvAF6BSrHeg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello everyone,
After following the discussion from afar, I am interested in implementing the
custom executor node for VLE.
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, so I was
wondering if it would not be better (or at least simpler in the long run) to
create a full GraphNode that would handle graph traversal (with recursion),
and do away with the query rewrite.
This node would only do the minimum possible (like respecting edge label) and
simply send the possible paths to the rest of the planner, in order to let it
decide what to do with WHERE clauses.
This has the benefits of not isolating the graph queries from the rest of the
planner.
What are your thoughts ?
[1]: https://www.postgresql.org/message-id/CAAAe_zAJz1nP3h2vHNi%2BwgN_cmzRcNpSHrUj8tRyP%2BVPexUwcg%40mail.gmail.com
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-07-21 15:03:17 | Re: pg19b1: TRAP: failed Assert("pgstat_bktype_io_stats_valid(bktype_shstats, MyBackendType)") |
| Previous Message | Robert Haas | 2026-07-21 14:06:51 | Re: document the dangers of granting TRIGGER or REFERENCES |