From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Simplify EXISTS subqueries containing LIMIT |
Date: | 2014-10-21 10:00:35 |
Message-ID: | CABRT9RBR5Bg22naun51pBB5Uj6Ey0RB5bSZe_VniZ4HusTdhag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
Thanks for taking a look.
On Sun, Oct 19, 2014 at 1:22 PM, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> the argument for this would
> have been much stronger if anti join support had just been added last week.
> It's been quite a few years now and the argument for this must be getting
> weaker with every release.
I see your point, but I would put it another way: we've had this for a
few years, but people haven't learned and are *still* using LIMIT 1.
----
Actually I thought of a cleverer approach to solve this, that doesn't
require calling eval_const_expressions and works with any expression.
Given query:
EXISTS (SELECT ... WHERE foo LIMIT any_expr())
we could turn it into the almost-equivalent form:
EXISTS (SELECT ... WHERE foo AND any_expr() > 0)
The only problem is that we'd no longer be able to throw an error for
negative values and that seems like a deal-breaker.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2014-10-21 10:23:00 | Re: [TODO] Track number of files ready to be archived in pg_stat_archiver |
Previous Message | Marti Raudsepp | 2014-10-21 09:30:33 | Re: Patch: Add launchd Support |