Thanks for all your valuable thoughts . It took me a while to read all your suggestions , still trying to understand it fully.
What we do with the text that I have mentioned is, we have search functionality on the text. The user enters some keywords and then the application should be able to search for all the text that matches the key word.
On Sat, Nov 13, 2010 at 7:21 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
On 11/13/2010 11:15 AM, Tom Lane wrote:
"Joshua D. Drake"<jd@commandprompt.com> writes:
On Sat, 2010-11-13 at 09:48 +0800, Craig Ringer wrote:
Thoughts, folks? Does this matter in practice, since anything you'd want
to index will in practice be small enough or a candidate for full-text
indexing?
I have run into this problem maybe 3 times in my whole career, precisely
because if you are dealing with text that big, you move to full text
search.
Yeah, the real question here is exactly what do you think a btree index
on a large text column will get you?
Of course, I've never run into this in practice, and if I did I'd be wondering if I had my schema design quite right. I can't imagine that the mostly aesthetic improvement of eliminating this indexing limitation would be worth the effort. I'd never ask or want anyone to waste their time on it, and don't intend to myself. Most of the interesting "big text" indexing problems are solved by tsearch and/or functional indexes.
--
Craig Ringer
