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

From Marti Raudsepp
Subject Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
Date
Msg-id CABRT9RBR5Bg22naun51pBB5Uj6Ey0RB5bSZe_VniZ4HusTdhag@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Simplify EXISTS subqueries containing LIMIT  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: [PATCH] Simplify EXISTS subqueries containing LIMIT
List pgsql-hackers
Hi

Thanks for taking a look.

On Sun, Oct 19, 2014 at 1:22 PM, David Rowley <dgrowleyml@gmail.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



pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Patch: Add launchd Support
Next
From: Julien Rouhaud
Date:
Subject: Re: [TODO] Track number of files ready to be archived in pg_stat_archiver