On Fri, Aug 20, 2004 at 11:17:14AM -0500, Jeremiah Jahn wrote:
> Correct me if I'm wrong, but don't you want to keep large objects out of
> the SQL, due to parsing overhead? Bytea, and text are capable of being
> used in place of LOs but the last time I tried that, things were so slow
> that it turned out to be useless. There for isn't it safe to say that
> the best you can ever do is to only pass a reference (OID) to the LO and
> not the actual LO itself in the SQL?

We started using BYTEA for storing binary large object data
when porting the Red Hat CMS from Oracle to PostgreSQL. We did
have some scalability issues with them, which turned out to be
a fundamental problem with the client/server protocol, which
required the client libs to do escaping of certain byte sequences.
For Java JDBC drivers this meant inserting a 20 MB binary file could
take as much as 100 MB of memory. This was with PG 7.2 and later
7.3. In the 7.4 release, the client/server protocol format went
through another revision, amongst other things, to deal with binary 
data much, much more efficiently. So if you've not looked at it
recently, it may be worth trying out BYTEA again.

cf  http://www.postgresql.org/docs/7.4/static/protocol-changes.html
    http://www.postgresql.org/docs/7.4/static/release-7-4.html

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20040820/f214dcaa/attachment.bin