Re: text type has no default operator class for GIN?
| От | Tom Lane |
|---|---|
| Тема | Re: text type has no default operator class for GIN? |
| Дата | |
| Msg-id | 8303.1250641309@sss.pgh.pa.us обсуждение |
| Ответ на | Re: text type has no default operator class for GIN? (Sam Mason <sam@samason.me.uk>) |
| Ответы |
Re: text type has no default operator class for GIN?
Re: text type has no default operator class for GIN? |
| Список | pgsql-general |
Sam Mason <sam@samason.me.uk> writes:
> On Tue, Aug 18, 2009 at 03:50:47PM -0600, Bob Gobeille wrote:
>>> CREATE INDEX "ufile_name_search" ON "public"."uploadtree" USING GIN
>>> ("ufile_name");
>>> ERROR: data type text has no default operator class for access method
>>> "gin"
> Not sure if understand very well myself, but GIN indexes can only speed
> up specific access patterns and these are exposed through various
> different operators.
What GIN indexes are good for is indexing equality queries on the
components of something the database otherwise thinks of as a single
object. For instance you can GIN-index searches for arrays containing
a particular value as a member.
Now type text doesn't have any built-in notion of a component, other
than individual characters, which aren't normally that interesting
to search for. What I suppose the OP has in mind is full-text
searching, which is looking for component *words*. But "word" is a
very language- and context-dependent concept. And defining which words
are to be considered equal for searching purposes is even more so.
If we'd hard-wired one notion of "word" into datatype text, it wouldn't
be very flexible. The point of the tsvector layer is to have a
configurable way to extract searchable words from a chunk of text.
There are also some implementation advantages like not having to repeat
that processing constantly during a search --- but the main point is
having a place to define what a word is and what search equality means.
regards, tom lane
В списке pgsql-general по дате отправления: