About reducing EXISTS sublink

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

About reducing EXISTS sublink

Richard Guo
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.)

For example:

# explain (costs off) select * from a where exists
                        (select avg(i) from b where a.i = b.i);
            QUERY PLAN
-----------------------------------
 Seq Scan on a
   Filter: (SubPlan 1)
   SubPlan 1
     ->  Aggregate
           ->  Seq Scan on b
                 Filter: (a.i = i)
(6 rows)

This query can be reduced to:

# explain (costs off) select * from a where exists
                        (select avg(i) from b where a.i = b.i);
  QUERY PLAN
---------------
 Seq Scan on a
(1 row)

And likewise, for this query below:

# explain (costs off) select * from a where exists
                        (select avg(i) from b where a.i = b.i offset 1);
               QUERY PLAN
-----------------------------------------
 Seq Scan on a
   Filter: (SubPlan 1)
   SubPlan 1
     ->  Limit
           ->  Aggregate
                 ->  Seq Scan on b
                       Filter: (a.i = i)
(7 rows)

It can be reduced to:

# explain (costs off) select * from a where exists
                        (select avg(i) from b where a.i = b.i offset 1);
        QUERY PLAN
--------------------------
 Result
   One-Time Filter: false
(2 rows)

Is it worthwhile to add some codes for such optimization? If so, I can
try to propose a patch.

Thanks
Richard
Reply | Threaded
Open this post in threaded view
|

Re: About reducing EXISTS sublink

David G Johnston
On Friday, May 22, 2020, Richard Guo <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: About reducing EXISTS sublink

Richard Guo

On Fri, May 22, 2020 at 10:59 PM David G. Johnston <[hidden email]> wrote:
On Friday, May 22, 2020, Richard Guo <[hidden email]> 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