Re: [PATCH] Rewrite undirected edge patterns in GRAPH_TABLE using UNION ALL

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Rewrite undirected edge patterns in GRAPH_TABLE using UNION ALL
Date: 2026-07-31 02:58:40
Message-ID: CAExHW5tbzsgykWN3j2qtny7HpXxAWzPDY_yq_Wzcub-ZLyHXcA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 30, 2026 at 9:20 PM Ayoub Kazar <ayoub(dot)kazar(at)data-bene(dot)io>
wrote:

>
> Also, given that the OR expansion was later replaced by cost based OR
> expansion, the transformation may not always yield optimal results. So, we
> should not always rewrite the undirected edge as UNION as the patch does.
>
> As mentioned above from what i noticed from some tests on Oracle query
> plans nearly everytime an OR expansion was applied, given both this patch's
> idea (UNION ALL only on edge table to generate two directions data -> then
> join separately) is a special case of the OR expansion, i find it
> interesting to see if we can try to prove that in all cases we would want
> this instead of the normal OR that mostly implies the bitmap scan ; which
> might suggest handling this "easier" case in rewrite for graph queries.
>

If OR transformation is implemented in the query optimizer, the
implementation in graph query is useless and, more seriously, misleading if
the correct statistics were to favour retaining OR.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Michael Paquier 2026-07-31 02:49:54 Re: Increase repalloc_array() usage in buffile.c