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
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. |