Re: Tsearch2 really slower than ilike ?

>
> QUERY PLAN
>----------------------------------------------------------------------------------------------------------------
> Seq Scan on site_rss s (cost=0.00..11863.16 rows=295 width=158) (actual
>time=17.414..791.937 rows=12 loops=1)
> Filter: (site_name ~~* '%atari%'::text)
> SubPlan
> -> Seq Scan on user_choice u (cost=0.00..3.46 rows=1 width=4) (actual
>time=0.222..0.222 rows=0 loops=12)
> Filter: ((id_site = $0) AND (id_user = 1))
> Total runtime: 792.099 ms
>
>First time I run the request I have a result in about 789 miliseconds !!???
>
>I'm using PostgreSQL v7.4.6 with a Bi-Penitum III 933 Mhz and 1 Gb of RAM.
>
>Any idea ... ? For the moment I'm going back to use the ilike solution ... but
>I was really thinking that Tsearch2 could be a better solution ...
>
>
>

Well I would be curious about what happens the second time you run the
query.
The first time is kind of a bad example because it has to push the index
into ram.

Sincerely,

Joshua D. Drake

>Regards,
>
>

--
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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL