Bruce Momjian <[EMAIL PROTECTED]> writes:
> Although the field length is limited to 1GB, is there a row size
> limit?
Sure. 1Gb per field (hard limit) times 1600 fields (also hard limit).
In practice less, since TOAST pointers are 20bytes each at present,
meaning you can't have more than BLCKSZ
> BTW, the postgres docs web pages says there is "no limitation" on row
> size. Someone should probably update that with the info given in the
> last few emails and probably integrate it in the regular doco as well.
Although the field length is limited to 1GB, is there a row size limit?
I don't
>Chris Bitmead <[EMAIL PROTECTED]> writes:
>> ... I don't
>> like the old large object implementation, I need to store very large
>> numbers of objects and unless this implementation has changed
>> in recent times it won't cut it.
>
>Have you looked at 7.1? AFAIK it has no particular probl
Chris Bitmead <[EMAIL PROTECTED]> writes:
> ... I don't
> like the old large object implementation, I need to store very large
> numbers of objects and unless this implementation has changed
> in recent times it won't cut it.
Have you looked at 7.1? AFAIK it has no particular problem with
lots o
Rod Taylor wrote:
> It should be noted that there is still a limit of about 1GB if I
> remember correctly.
You're right, there is still a practical limit on the size of
a text field. And it's usually much lower than 1GB.
The problem is that first, the (encoded) data has to be put
On Wed, Oct 10, 2001 at 11:33:04AM +1000, Chris Bitmead wrote:
> So my question is, I assume TEXT is the best data type to store
> large things in, what precisely is the range of characters that
> I can store in TEXT? Is it only characters ascii <= 127, or is
> it only printable characters, or eve
lt;[EMAIL PROTECTED]>
Sent: Tuesday, October 09, 2001 9:33 PM
Subject: [HACKERS] TOAST and TEXT
> Hi,
>
> Now that postgresql doesn't have field size limits, it seems to
> me they should be good for storing large blobs, even if it means
> having to uuencode them to be non-
Hi,
Now that postgresql doesn't have field size limits, it seems to
me they should be good for storing large blobs, even if it means
having to uuencode them to be non-binary or whatever. I don't
like the old large object implementation, I need to store very large
numbers of objects and unless thi
