Re: [PATCH] Simplify EXISTS subqueries containing LIMIT

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

In response to

Responses

Browse pgsql-hackers by date

  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