Re: index row requires 10040 bytes, maximum size is 8191

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(at)postnewspapers(dot)com(dot)au>wrote:

> On 11/13/2010 11:15 AM, Tom Lane wrote:
>
>> "Joshua D. Drake"<jd(at)commandprompt(dot)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?
>>
>
> About the only useful case I can see is with text data of very irregular
> size. The vast majority is small, but there are a few massively bigger
> items. It'd be nice if the index method had a fallback for items too big to
> index in this case, such as a prefix match and heap recheck.
>
> 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
>