Re: [HACKERS] Solution for LIMIT cost estimation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Solution for LIMIT cost estimation
Date
Msg-id 19478.950281624@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Solution for LIMIT cost estimation  (Don Baccus <dhogaza@pacifier.com>)
List pgsql-hackers
Don Baccus <dhogaza@pacifier.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] libpq