Re: [HACKERS] Solution for LIMIT cost estimation
| От | Chris Bitmead |
|---|---|
| Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
| Дата | |
| Msg-id | 38A3B2F7.286CD6ED@nimrod.itg.telecom.com.au обсуждение исходный текст |
| Ответ на | Solution for LIMIT cost estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Solution for LIMIT cost estimation
|
| Список | pgsql-hackers |
Don Baccus wrote: > 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? select count(*) > 1 from a; And if that's not efficient, why not optimise _that_, since it expresses directly what you want? > But I wouldn't feel badly at all if LIMIT limited to queries > with ORDER BY. I think this could be done gramatically, i.e. > > [query] ORDER BY If you are going to limit it thus, it only makes sense if you either order by a unique key or order by every single column. Otherwise, why limit it at all? And that can't be determined gramatically.
В списке pgsql-hackers по дате отправления: