I'll give it a try, that was the exact problem I had

On Fri, 2004-08-20 at 11:36, Daniel P. Berrange wrote:
> 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.
-- 
Jeremiah Jahn <jeremiah at cs.earlham.edu>