Re: Slow count(*) again... - Mailing list pgsql-performance

From Pierre C
Subject Re: Slow count(*) again...
Date
Msg-id op.vkhfkn1yeorkce@apollo13
Whole thread Raw
In response to Re: Slow count(*) again...  (Neil Whelchel <neil.whelchel@gmail.com>)
Responses Re: Slow count(*) again...  (Mladen Gogala <mladen.gogala@vmsinfo.com>)
Re: Slow count(*) again...  (Neil Whelchel <neil.whelchel@gmail.com>)
List pgsql-performance
> suggest that 99% instances of the "select count(*)" idiom are probably
>> bad use of the SQL language.

Well, suppose you paginate results. If the user sees that the search query
returns 500 pages, there are two options :

- you're google, and your sorting algorithms are so good that the answer
the user wants is in the first page
- or the user will refine his search by entering more keywords tu get a
manageable result set

So, in both cases, the count(*) was useless anyway. And the slowest ones
are the most useless, since the user will immediatey discard the result
and refine his query.

If your full text search is slow, try Xapian or Lucene.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: bulk load performance question
Next
From: Neil Whelchel
Date:
Subject: Re: Slow count(*) again...