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
