I used the full text search built into postgresql a couple years ago. Worked great, can't talk about performance compared to anything else but it was fast enough for us. I was replacing the use of xapian because it was difficult to manage and maintain/update. As Breccan said, less points of failure.
I think the way I used it, it auto updated the full text indexes. For a write intensive application you might need to do something extra or another solution, but for primarily reads I think it is brilliant. Another point is having the search inside your DB you can do the normal DB things like sort, limit, join... Which can be really really helpful, instead of having to communicate between the DB and a search server. I haven't used sphyx or solr so can't comment or compare. On 18 May 2011 14:51, Tim Uckun <[email protected]> wrote: > On Wed, May 18, 2011 at 2:11 PM, Breccan McLeod-Lundy > <[email protected]> wrote: > > Text search in postgres can update smoothly with DB triggers and be > > very speedy if it happens to fit your needs. Unlike the other options > > with that periodic indexing. Also, less points of failure. > > > > The peepcode postgres screencast has a very nice overview of it. > > > > -Breccan > > What is the performance like compared to sphyx or solr. Also how much > additional load does it put on your database? > > -- > You received this message because you are subscribed to the Google Groups > "WellRailed" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wellrailed?hl=en. > > -- You received this message because you are subscribed to the Google Groups "WellRailed" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.
