| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: About reducing EXISTS sublink |
| Date: | 2020-05-22 14:59:51 |
| Message-ID: | CAKFQuwb_eHQQDuExNr65aTQ74X11F=btb-izK18r3GvnCtZJUA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2020-05-22 15:14:38 | Re: password_encryption default |
| Previous Message | Tom Lane | 2020-05-22 14:59:34 | Re: password_encryption default |