From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: About reducing EXISTS sublink |
Date: | 2020-05-26 02:23:22 |
Message-ID: | CAMbWs4_cwXas6PqiaFhkPXFRVCfB69EXZyh0tqLCCiAv+GgcEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 22, 2020 at 10:59 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> On Friday, May 22, 2020, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>
>> Hi hackers,
>>
>> For EXISTS SubLink, in some cases the subquery can be reduced to
>> constant TRUE or FALSE, based on the knowledge that it's being used in
>> EXISTS(). One such case is when the subquery has aggregates without
>> GROUP BY or HAVING, and we know its result is exactly one row, unless
>> that row is discarded by LIMIT/OFFSET. (Greenplum does this.)
>>
>> Is it worthwhile to add some codes for such optimization? If so, I can
>> try to propose a patch
>>
>
> While the examples clearly demonstrate what you are saying they don’t
> provide any motivation to do anything about it - adding aggregates and
> offset to an exists subquery seems like poor query design that should be
> fixed by the query writer not by spending hacker cycles optimizing it.
>
Thanks David. I have the same concern that this case is not common
enough to worth hacker cycles.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-05-26 02:27:34 | Re: Default gucs for EXPLAIN |
Previous Message | Dilip Kumar | 2020-05-26 02:15:19 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |