Re: [SQL/PGQ] Native executor for Graph query

Hello everyone,
I updated the patch to allow queries with partitioning, inheritance, foreign
tables, and views, to work properly. Queries with lateral syntax will evaluate
WHERE statements outside the graph to produce identical results to the
rewriter pass.
The patch aims to completely replace the rewriter system for graph queries.

I am open to any feedback you may have, and I can split the patches in
smaller ones if this would help you review them better.

Best regards,
Henri GASC

On Sat, Aug 8, 2026 at 11:53 AM Henri GASC <henri(dot)gasc(at)airbus(dot)com> wrote:
>
> Hello everyone,
> After my previous email[1] I started to work on the custom node for VLE.
> I managed to do it, but then I encountered a problem: it was
> impossible to mix VLE and non-VLE patterns in a single query.
> Therefore, I started working on a native planner / executor for graph
> queries, you can find the result attached.
>
> The feature is behind the GUC enable_native_graphtable (set to ON by
> default), so switch to OFF to use the rewrite system.
>
> There are some caveats:
> - I did not start working on inheritance, partitioning, foreign
> tables, and views, so queries on it may be inconsistent.
> - Row level security is not something I even started to approach, so
> expect lot of errors.
> - Queries with lateral syntax are finicky at best, so tread carefully.
>
> I have questions concerning the latter (and sorry if it was already
> litigated in the original thread).
> In the regression tests (for example graph_table.sql, line 161), we
> have the query "SELECT * FROM x1, GRAPH_TABLE (...);".
> According to the documentation, we are supposed to take the Cartesian
> product of both tables.
> x1 is defined with two rows, so we should get two rows (because there
> is a single customer with adress = 'US'). What we
> currently expect however, is the result of a simple JOIN on graph.cid and x1.a.
> The question is then: How should the native executor handle those
> cases ? I think rejecting the query outright is sensible,
> as in those cases, x1 is not properly defined.
> The same question applies to the other test with multiple sources in
> SELECT, and in general to the LATERAL behaviour.
>
> For the future (should this patch be accepted), then I (or other) can
> work on supporting other path_mode (currently only
> WALK is used), other graph traversal algorithms (BFS, Bidirectional,
> or for some insane reason A*), and add ways to make
> use of the optimizer (push down WHERE / IS conditions, use indexes,
> split hop patterns and group afterwards, etc.).
>
> I also attached the graph links I used to write the expected output
> for the VLE tests.
>
> Best regards,
> Henri GASC
>
> [1]: https://www.postgresql.org/message-id/flat/CAJyuuthCZ8yQuUAy_1d0DkxtdQ_aZcOX%2B7bcwagwvAF6BSrHeg%40mail.gmail.com
>
> Classification: Privacy: Basic Personal Data; Export Control: Not
> Technical; National Security: Not National Security; Company
> Classification: Not Applicable; Business or Private Data: Business
> data
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.