[PATCH] Simplify EXISTS subqueries containing LIMIT - Mailing list pgsql-hackers

From Marti Raudsepp
Subject [PATCH] Simplify EXISTS subqueries containing LIMIT
Date
Msg-id CABRT9RBJZAdvFrefxJWfzpribnJSh4J_qL3jYQYojgNSrw=+BQ@mail.gmail.com
Whole thread Raw
Responses Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
List pgsql-hackers
Hi list,

Attached patch allows semijoin/antijoin/hashed SubPlan optimization
when an EXISTS subquery contains a LIMIT clause with a positive
constant. It seems to be a fairly common meme to put LIMIT 1 into
EXISTS() subqueries, and it even makes sense when you're not aware
that the database already does this optimization.

Do we want this?

It has come up in #postgresql, and at twice times on mailing lists:
http://www.postgresql.org/message-id/53279529.2070902@freemail.hu
http://www.postgresql.org/message-id/50A36820.4030400@pingpong.net

And there may even be good reasons, such as writing performant
portable SQL code for Other Databases:
https://dev.mysql.com/doc/refman/5.1/en/optimizing-subqueries.html

----
The code is fairly straightforward. The only ugly part is that I need
to call eval_const_expressions() on the LIMIT expression because
subquery_planner() does subquery optimizations before constant
folding. A "LIMIT 1" clause will actually produce an int8(1)
expression. And I have to drag along PlannerInfo for that.

If it fails to yield a constant we've done some useless work, but it
should be nothing compared to the caller doing a deep copy of the
whole subquery.

Regards,
Marti

Attachment

pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: DDL Damage Assessment
Next
From: Alvaro Herrera
Date:
Subject: Re: DDL Damage Assessment