BUG #18904: INTERSECT with an impossible where should eliminate both from the query plan
| От | David G. Johnston |
|---|---|
| Тема | BUG #18904: INTERSECT with an impossible where should eliminate both from the query plan |
| Дата | |
| Msg-id | CAKFQuwYDxYLNEODZhBL=7iR-7gGfrcFCz=AUBaw2=WEYrjMbhA@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #18904: INTERSECT with an impossible where should eliminate both from the query plan (PG Bug reporting form <noreply@postgresql.org>) |
| Ответы |
Re: BUG #18904: INTERSECT with an impossible where should eliminate both from the query plan
|
| Список | pgsql-bugs |
On Sunday, April 27, 2025, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 18904
Logged by: jinhui lai
Email address: jh.lai@qq.com
PostgreSQL version: 17.4
Operating system: ubuntu
Description:
Dear Postgres Developer,
If you have a query of the form:
Q1 INTERSECT Q2 ... INTERSECT Qn,
In such cases, you know that query Qn always returns an empty set(e.g., a
query with WHERE 1=2), then the entire intersection will always be empty.
I think that such queries should be eliminated during optimization, as they
will always return an empty set and should never consume execution time.
These failure to optimize requests are not bugs and are better discussed on the -general list where some sense of demand can be ascertained.
There is little desire to evaluate where clause expressions in the manner you propose, and while executing the subcomponents in most-restrictive to least-restrictive would be nice - stopping should any of them return no rows - it’s seems like quite a niche situation to spend time on.
David J.
В списке pgsql-bugs по дате отправления: