| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | jesper(at)krogh(dot)cc, pgsql-performance(at)postgresql(dot)org, oleg(at)sai(dot)msu(dot)su, teodor(at)sigaev(dot)ru |
| Subject: | Re: Queryplan within FTS/GIN index -search. |
| Date: | 2009-11-03 15:35:44 |
| Message-ID: | 4730.1257262544@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Perhaps I'm missing something. My point was that there are words
> which are too common to be useful for index searches, yet uncommon
> enough to usefully limit the results. These words could typically
> benefit from tsearch2 style parsing and dictionaries; so declaring
> them as stop words would be bad from a functional perspective, yet
> searching an index for them would be bad from a performance
> perspective.
Right, but the original complaint in this thread was that a GIN index is
slow about searching for very common terms. The answer to that clearly
is to not index common terms, rather than worry about making the case
a bit faster.
It may well be that Jesper's identified a place where the GIN code could
be improved --- it seems like having the top-level search logic be more
aware of the AND/OR structure of queries would be useful. But the
particular example shown here doesn't make a very good case for that,
because it's hard to tell how much of a penalty would be taken in more
realistic examples.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2009-11-03 16:49:31 | Re: Queryplan within FTS/GIN index -search. |
| Previous Message | Kevin Grittner | 2009-11-03 15:13:43 | Re: Problem with database performance, Debian 4gb ram ? |