Re: Large Objects

On Sat, Jan 01, 2005 at 01:28:04PM +0300, Michael Ben-Nes wrote:
> Joshua D. Drake wrote:
> >Frank D. Engel, Jr. wrote:
> >>I'd advise use of BYTEA as well.  It's much simpler to work with than
> >>the OIDs, and has simpler semantics.  You do need to escape data
> >>before handing it to the query string, and handle escaped results
> >>(see the docs), but overall much nicer than working with OIDs.
> >
> >
> >BYTEA is not always pragmatic. What is the file is 100 megs? 256 megs?
> >
> Intresting.
> What is the size when bytea become inafective ?

I don't think it's so much a matter of effectiveness, it makes no
difference at all in storage space. The issue is that if you store it
in a field, accessing it becomes an all or nothing affair, which means
if it's a 100Mb object, it's all going to be accessed whenever you ask
for it. OTOH, large objects have lo_read/write/seek meaning you can
access small parts at a time.

So I imagine if you're storing large PDF files and all you're doing is
dumping them to a client when they ask, it doesn't matter. But if the
objects have structure and you might be interested in looking inside
them without pulling the whole object down, the LO interface is better
suited.

When you delete a row, the object contained in it goes away too. Large
Objects have a lifecycle outside of normal table values, and so may
need separate managing...

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.