Hey all, its me again. If I do not do a count(product_id) on my
tsearch2 queries, its actually really fast, for example;
explain analyze SELECT product_id FROM product, to_tsquery('bear') AS q
WHERE vector @@ q LIMIT 1000;
QUERY PL
Kris,
is't possible to share your "paragraph generator" ? It'd be better than
downloading the whole dump :)
On Wed, 29 Sep 2004, Kris Kiger wrote:
> Oleg, the data I have right now was generated using a random paragraph
> generator. The words are real words, but there are only 508 distinct
> ke
Oleg, the data I have right now was generated using a random paragraph
generator. The words are real words, but there are only 508 distinct
keywords in the 3,000,000 records that tsearch2 will pick up, using
default settings. I was using this data set for the purpose of testing
tsearch2's cap
Kris,
we're working on prototype of tsearchd - full text search daemon, which
maintain static inverted index outside of postgresql using the same
parser, dictionary tsearch2 does. This approach could scale up
fts capability preserving access to metadata, so yo may have
"archive" part of your coll
Kris Kiger wrote:
> search_test=# explain analyze SELECT count(q) FROM product,
> to_tsquery('oil') AS q WHERE vector @@ q;
> QUERY PLAN
>
--
On Mon, 27 Sep 2004, Kris Kiger wrote:
> Yes, it is much better than no index of sequential scan. We may just be
> looking at the best performance tsearch2 can offer on my machine.
Hmm,
tsearch2 with no index should be faster than LIKE, because tsearch2
already has *parsed* and *sorted* list.
On Mon, 27 Sep 2004, 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. M
Yes, it is much better than no index of sequential scan. We may just be
looking at the best performance tsearch2 can offer on my machine.
search_test=# explain analyze SELECT count(q) FROM product,
to_tsquery('oil') AS q WHERE vector @@ q;
wipe the cache(s).
Greg Williamson
DBA
GlobeXplorer LLC
-Original Message-
From: Kris Kiger [mailto:[EMAIL PROTECTED]
Sent: Friday, September 24, 2004 2:59 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADMIN] tsearch2 poor performance
Here is the explain analyze output, funny thing, after
Here is the explain analyze output, funny thing, after I ran josh's
query, mine ran a lot fastermaybe it forced a caching?;
search_test=# explain analyze select count(*) from product where vector
@@ to_tsquery('oil');
Aggregate (cost=6113.09..6113.09 rows=1 width=0) (actual
time=19643.372.
Kris,
could you post 'explain analyze' output ?
Also, could you disable index usage (set enable_indexscan=off)
and rerun search using tsearch2 ?
also, could you run 'stat' function to see frequency distribution
of words. See http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_Notes
for det
Hi all. I am doing some work with tsearch2 and am not sure what to
expect out of it, performance wise. Here is my setup:
Table "public.product"
Column| Type |Modifiers
-+--+---
12 matches
Mail list logo
