Re: [HACKERS] Solution for LIMIT cost estimation
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
Дата | |
Msg-id | 19478.950281624@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Solution for LIMIT cost estimation (Don Baccus <dhogaza@pacifier.com>) |
Список | 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 по дате отправления: