From: | "Poul L(dot) Christiansen" <poulc(at)cs(dot)auc(dot)dk> |
---|---|
To: | Andrew McMillan <Andrew(at)catalyst(dot)net(dot)nz> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Mitch Vincent <mitch(at)venux(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Full text indexing (Question/request) |
Date: | 2000-10-17 11:28:16 |
Message-ID: | 39EC37D0.43EA74F5@cs.auc.dk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew McMillan wrote:
>
> Bruce Momjian wrote:
> >
> > See contrib/fulltextindex.
>
> An easy answer, but not a very good solution in the real world.
>
> contrib/fulltextindex requires you to jump through hoops in developing
> queries to retrieve your data. It's also very space-inefficient in that
> a table with a fulltextindex on a field needs another table with a
> complete set of values for that field, as well as any substrings of that
> field, and then it wants two indexes on that table. Add that up!
>
> It would be nice to see a true index which was full text. It would be
> nice to see a true index which allowed an individual field to index to
> many entries through a function interface. This would straightforwardly
> allow people to create their own simple functions to perform full-text,
> keyword or other indexing schemes quite simply.
>
> It naively appears to me that the function interface is moving closer to
> achieving this with the enhancements in 7.1 to the use of setof()
> returns combined with the earlier enhancement to indexing on function
> results.
>
> If a function fulltextindex(text) returned a setof() the substrings in
> its text argument, how hard will it be to index on that return value and
> allow WHERE field=fulltextindex('substring') to use that index?
>
> Of course such a fulltextindex() function would have to know not to do
> any processing on the string when called in the second situation. Is it
> possible for functions to do this sort of trick? It seems a bit beyond
> the pale!
>
> I would _love_ to see full-text or keyword indexing natively in
> PostgreSQL.
I tottally agree with you. FTI is not a good solution. It seems natural
that PostgreSQL will have a built-in (and better) FTI, now that the
TOAST project will be implemented in 7.1.
Poul L. Christiansen
From | Date | Subject | |
---|---|---|---|
Next Message | chris markiewicz | 2000-10-17 11:37:33 | do triggers/procedures run instantly? |
Previous Message | Hannu Krosing | 2000-10-17 11:16:24 | Re: pgsql is 75 times faster with my new index scan |