I will look that tsearch (at . It appears their 8.1.x version is
still in development and I use PostgreSQL 8.1.3 but it is worth trying
- I'm not in a hurry for that feature anyway.
I also looked at PHPBB a little - it appears their database stores
words but the code is so difficult to dig through I was not sure about
their implementation or even what they used it for. Would it be worth
the work to save the text into a separate searchable table that kept
individual words and word counts or would that be more work and eat up
more space than it is worth? You could actually index the words that
way and get much quicker searches. Then again, as I read through
tsearch, it may make this approach unnecessary...
I have also seen what looks like people using search results tables
that, after a search is performed, save a list of the results. For
example, if I were doing a search of a forum, I could save the search
in a table like this:
forum_topic forum_topic_id (PK) forum_topic_name etc...
forum_topic_search forum_topic_search_id (PK) forum_topic_search_dt forum_topic_search_desc
forum_topic_search_results forum_topic_search_results_id (PK) forum_topic_search_id (FK) sort_index (int to tell us
theorder the results are returned in) forum_topic_id (FK)
This way you can allow users to page through the results without
having to constantly research or cache the results somewhere in
memory.
Has anyone tried an approach like this?
When do you clean these search tables out? They could get quite large
after a while.
Thanks!
Aaron
On 6/13/06, Rod Taylor <pg@rbt.ca> wrote:
> It won't help at all. Fast partial matches against arrays is nearly
> impossible. You might take a look at tsearch though.
