Re: [HACKERS] Solution for LIMIT cost estimation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: chris(at)bitmead(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Date: 2000-02-11 15:07:04
Message-ID: 19478.950281624@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Don Baccus <dhogaza(at)pacifier(dot)com> writes:
> Well ... for my money I never expected LIMIT to be meaningful in
> the sense of being deterministic without an ORDER BY clause.

> But ... that doesn't mean that some folks might not want to use
> it differently. What if LIMIT 2 were more efficient that COUNT(*)
> in order to determine if more than one row satisfies a condition?

Hmm, that's an excellent example indeed. A slight variant that is
even more plausible is LIMIT 1 when you just want to know if there
is any tuple satisfying the WHERE condition, and you don't really
care about which one you get.

> I don't know if that's even a remote possibility given the current
> implementation,

Absolutely --- COUNT(*) doesn't provide any way of stopping early,
so a LIMITed query could be far faster. Given an appropriate plan
of course. The problem right now is that the optimizer is quite
likely to pick the wrong plan.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-02-11 15:10:13 Re: [HACKERS] libpq
Previous Message Tom Lane 2000-02-11 14:59:59 Re: [HACKERS] Solution for LIMIT cost estimation