Re: tsearch2/GIST performance factors?
От | Craig A. James |
---|---|
Тема | Re: tsearch2/GIST performance factors? |
Дата | |
Msg-id | 4354913B.2020001@modgraph-usa.com обсуждение исходный текст |
Ответ на | Re: tsearch2/GIST performance factors? (Oleg Bartunov <oleg@sai.msu.su>) |
Ответы |
Re: tsearch2/GIST performance factors?
|
Список | pgsql-performance |
Oleg wrote: > Did you consider *decreasing* SIGLENINT ? Size of index will diminish > and performance could be increased. I use in current project SIGLENINT=15 The default value for SIGLENINT actually didn't work at all. It was only by increasing it that I got any performance atall. An examination of the GIST indexes showed that most of the first level and many of the second level bitmaps weresaturated. > tsearch2's index is a lossy index, read > http://www.sai.msu.su/~megera/oddmuse/index.cgi/Tsearch_V2_internals > so search results should be rechecked ! Yes, thanks. We do indeed recheck the actual results. The tests I'm running are just on the raw index performance - howlong does it take to "select ... where dockeys @@ to_tsquery(...)". > We have our TODO http://www.sai.msu.su/~megera/oddmuse/index.cgi/todo > and hope to find sponsorhips for fts project for 8.2 release. > Unfortunately, I didn't find spare time to package tsearchd for you, > it should certainly help you. At this point we may not have time to try tsearchd, and unfortunately we're not in a position to sponsor anything yet. My original question is still bothering me. Is it normal for a keyword that occurs in more than about 2% of the documentsto cause such inconsistent performance? Is there any single thing I might look at that would help improve performance(like, do I need more memory? More shared memory? Different config parameters?) Thanks, Craig
В списке pgsql-performance по дате отправления: