Re: About reducing EXISTS sublink

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

In response to

Browse pgsql-hackers by date

  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