Marc G. Fournier wrote:
'k, I'm obviously doing something wrong, since my experiences with sites
like fts.postgresql.org indicate things should be *alot* faster then I'm
getting ...
Well the first thing I would ask is are you running 8.0? My testing
shows that Tsearch is pretty abysmal if you are not running 8.0. At
least with very large tables.
I have a *very* simple table:
=# \d article_tsearch
Table "public.article_tsearch"
Column | Type | Modifiers
------------+----------+-----------
article_id | integer |
idxft1 | tsvector |
Indexes:
"at_idxft1_idx" gist (idxft1)
rblog=# select count(1) from article_tsearch;
count
--------
643072
(1 row)
Is there something else I should be doing to speed the query up any? Or
is this fairly normal?
Considering the number of rows I am not that surprised but I would be
curious to know what type of HD you have? Also correct me if I am wrong
but gist indexes are typically very large. Do you have enough
work_mem/sort_mem to keep them from going to disk?
Sincerely,
Joshua D. Drake
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@xxxxxxx Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
--
Your PostgreSQL solutions provider, Command Prompt, Inc.
24x7 support - 1.800.492.2240, programming, and consulting
Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit
http://www.commandprompt.com / http://www.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
