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