Re: Slow count(*) again...
От | Mladen Gogala |
---|---|
Тема | Re: Slow count(*) again... |
Дата | |
Msg-id | 4CB3A2CC.9070009@vmsinfo.com обсуждение исходный текст |
Ответ на | Re: Slow count(*) again... (Neil Whelchel <neil.whelchel@gmail.com>) |
Ответы |
Re: Slow count(*) again...
|
Список | pgsql-performance |
On 10/11/2010 3:54 PM, Neil Whelchel wrote: > 1. A faster count(*), or something like my proposed estimate(*). > 2. A way to get the total rows matched when using LIMIT and OFFSET before > LIMIT and OFFSET are applied. The biggest single problem with "select count(*)" is that it is seriously overused. People use that idiom to establish existence, which usually leads to a performance disaster in the application using it, unless the table has no more than few hundred records. SQL language, of which PostgreSQL offers an excellent implementation, offers [NOT] EXISTS clause since its inception in the Jurassic era. The problem is with the sequential scan, not with counting. I'd even go as far as to suggest that 99% instances of the "select count(*)" idiom are probably bad use of the SQL language. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com
В списке pgsql-performance по дате отправления: