Message-ID: <4CB4E18E.2060906@vmsinfo.com>
Date: Tue, 12 Oct 2010 18:30:38 -0400
From: Mladen Gogala <mladen.gogala@vmsinfo.com>
Organization: VMS
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Pierre C <lists@peufeu.com>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
	Neil Whelchel <neil.whelchel@gmail.com>
Subject: Re: Slow count(*) again...
References: <201010091626.18636.neil.whelchel@gmail.com>
	<201010111254.58479.neil.whelchel@gmail.com>
	<4CB3A2CC.9070009@vmsinfo.com>
	<201010111936.46207.neil.whelchel@gmail.com>
	<op.vkhfkn1yeorkce@apollo13>
In-Reply-To: <op.vkhfkn1yeorkce@apollo13>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Pierre C wrote:
>>
>
> Well, suppose you paginate results. If the user sees that the search query  
> returns 500 pages, there are two options :
>   
With Google, I usually lose patience on the page 3. All that I, as an 
end user, need to know is whether there are  more than 10 pages. The 
fact that there are 1776 pages in the result set is not particularly 
useful to me. I couldn't care less whether the number of returned pages  
is 1492, 1776 or 1861, I'm going to look at, at most, the first 5 of them.

> - 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.
>
>   
May I also recommend Sphinx? It's a very nice text search engine, with 
the price equal to that of Lucene.


-- 
 
Mladen Gogala 
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
http://www.vmsinfo.com 
The Leader in Integrated Media Intelligence Solutions