Re: TOAST and TEXT

From: Chris Bitmead <chris(at)bitmead(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: TOAST and TEXT
Date: 2001-10-11 05:24:33
Message-ID: 3BC52D11.7080300@bitmead.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Chris Bitmead <chris(at)bitmead(dot)com> 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 of LOs.
>
>Which is not to discourage you from going over to bytea fields instead,
>if that model happens to be more convenient for your application.
>But your premise above seems false.

I'm storing emails, which as we know are usually small but occasionally
huge. OK, I see in the release notes something like "store all large
objects in one table". and "pg_dump" of large objects. That sounds like
maybe LOs are now ok, although for portability with Oracle blobs it
would be nice if they could be embedded in any row or at least appear
to be so from client interface side (Java client for what I'm doing).

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.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-10-11 05:37:49 Re: row value constructor bug?
Previous Message Tom Lane 2001-10-11 05:21:25 Re: Postgres server locks up