Re: tsearch2 poor performance

Hello,

I might of missed this on a previous message, BUT what type of hardware
are we dealing with here? Is it possible that we just don't have enough
IO/RAM to push this?

J


Kris Kiger wrote:
> Oleg,
>
>    Thanks for the help on this.
>
>    The query I used to return the 508 number is:
>         SELECT * FROM stat('SELECT vector FROM product') ORDER BY ndoc
> desc, word ;
>      Testing says, the more words I use, the faster the query is.  My
> original search word, 'oil', appears in 226,357 documents 233,266 times.
> As far as distinct words go, 'oil' is middle of the road for
> occurences.  As it is set up now, the best search time I am getting on
> this single word is roughly 22 seconds.
> Kris
>
> Oleg Bartunov wrote:
>
>> Kris,
>>
>> do you actually have only 508 disctinct words ? Could you try
>> more complex queries, say 2-3 words. Does these queries run faster ?
>>
>>
>>     Oleg
>> On Mon, 27 Sep 2004, Kris Kiger wrote:
>>
>>
>>
>>> Regardless of caching, the queries are still taking 19~20 seconds to run
>>> on the 3,000,000 rows.  I've played with performance tuning and nothing
>>> seems to make much of a difference.  If I am reading that list from stat
>>> correctly, then I am operating on  508 distinct words.  Is this the
>>> performance I should expect from tsearch2?  Or is something still awry?
>>> I'm inclined to think  something else is wrong, after reading some
>>> other people's tsearch performance stats.  Thanks!
>>>
>>> Kris
>>>
>>>
>>
>>     Regards,
>>         Oleg
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster


--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL