[PATCH] Simplify EXISTS subqueries containing LIMIT

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: [PATCH] Simplify EXISTS subqueries containing LIMIT
Date: 2014-10-02 21:41:19
Message-ID: CABRT9RBJZAdvFrefxJWfzpribnJSh4J_qL3jYQYojgNSrw=+BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0001-Simplify-EXISTS-subqueries-containing-LIMIT.patch text/x-patch 5.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-10-02 21:41:20 Re: DDL Damage Assessment
Previous Message Simon Riggs 2014-10-02 21:37:58 Re: Assertion failure in syncrep.c