On 11/13/2010 11:15 AM, Tom Lane wrote:
"Joshua D. Drake"<jd@xxxxxxxxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
