At 02:41 PM 2/26/00 +0200, Hannu Krosing wrote:
>Rather "maximum number of characters you can store in a column of type
> text is limited by available memory and/or disk space"
TOAST is obviously ideal, so in a sense this discussion's pointless
because I have no doubt TOAST will happen.
We could still put an 8KB upper limit on a compressed text type if
we wish. The size savings would be a plus, and you'd be able to
have full-sized 8KB text columns in many tables, at least, that carry
a bunch of other cruft around.
That's really the problem I run in porting over the web toolkit
from arsDigita.
I see tables that have two or three varchar(4000) columns with other
data, i.e. names and stuff that are also varchar but smaller. I know
that these don't actually get stuffed with 4000 chars but rather
that 4KB is the upper limit of the size of an Oracle varchar and that
the author's been lazy. If I had a compressed text or varchar type
I'd be quite confident that the application code would run even with
an 8KB block size.
In the interim. Until TOAST comes or until I have time to dig into
the code and determine more accurate and reasonable sizes for the
varchars.
On the other hand, as I've mentioned I'm also just as happy to run
with a 16KB block size. From the point of view of distributing the
web toolkit, some of our little group feel uncomfortable with that
requirement but it doesn't really bother me as I know TOAST will solve
the problem and that by end of year we'll be able to run the toolkit
on a default installation of Postgres.
So I'm happy, I run with a 16KB block size and eagerly await TOASTed
tuples.
- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.