On Tue, 22 Mar 2005 15:36:11 +0300 (MSK), Oleg Bartunov <oleg@sai.msu.su> wrote:
use something like echo "150000000" > /proc/sys/kernel/shmmax to increase shared memory. In your case you could dedicate much more memory.
Regards, Oleg
Thanks, I'll check that out.
And Oleg should know. Unless I'm mistaken, he (co)wrote tsearch2. Other than shared buffers, I can't imagine what could be causing that
kind of slowness. EXPLAIN ANALYZE, please?
ilab=# explain analyze select count(titel) from books where idxfti @@ to_tsquery('default', 'buckingham | palace');
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=35547.99..35547.99 rows=1 width=56) (actual time=125968.119..125968.120 rows=1 loops=1)
-> Index Scan using idxfti_idx on books (cost=0.00..35525.81 rows=8869 width=56) (actual time=0.394..125958.245 rows=3080 loops=1)
Index Cond: (idxfti @@ '\'buckingham\' | \'palac\''::tsquery)
Total runtime: 125968.212 ms
(4 rows)
Time: 125969.264 ms ilab=#
> As an example of what I think you *should* be seeing, I have a similar > box (4 procs, but that doesn't matter for one query) and I can search > a column with tens of millions of rows in around a second. >
That sounds very promising, I'd love to get those results.. could you tell me what your settings are, howmuch memory you have and such? Thanks.
Rick
-- Systems Administrator for Rockingstone IT http://www.rockingstone.com http://www.megabooksearch.com - Search many book listing sites at once
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
