| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Michael Paquier | 2026-07-31 02:49:54 | Re: Increase repalloc_array() usage in buffile.c |