Re: Queryplan within FTS/GIN index -search.

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-performance(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: Queryplan within FTS/GIN index -search.
Date: 2009-10-31 08:55:34
Message-ID: 407d949e0910310155m247d4947i6b794c0ce852bd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Oct 30, 2009 at 8:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> But having said that, this particular test case is far from compelling.
> Any sane text search application is going to try to filter out
> common words as stopwords; it's only the failure to do that that's
> making this run slow.

Well it would be nice if that wasn't necessary. There are plenty of
applications where that isn't really an option. Consider searching for
phrases like "The The" or "The Office". The sanity of doing this is
purely a function of implementation quality and not of actual user
interface design.

--
greg

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2009-10-31 13:03:30 Re: Modeling a table with arbitrary columns
Previous Message Jesper Krogh 2009-10-31 06:20:48 Re: Queryplan within FTS/GIN index -search.