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 |
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 |