Обсуждение: TOAST, large objects, and ACIDity

Hi all,

I want to use postgres to store data and large files, typically audio
files from 100ko to 20Mo. For those files, I just need to store et
retrieve them, in an ACID way. (I don't need search, or substring, or
others functionnalities)
I saw postgres offers at least 2 method : bytea column with TOAST, or
large objects API.

I wonder what are the differences of the 2 methods.
 * I found that large objects need a vacuum after delete to really
release place. That may be handled by a trigger or automatic vaccum, is
it right ?
 * Large objects are used via a special API available in libpq C client
library.
 * I really care keeping my transaction fully ACID. Documentation on
large objects doesn't explicitly say if lo_import an lo_export (and
other primitives) are fully ACID. Some ideas ?
 * I going to bench insertion and read with this 2 methods.

other advices are wellcome.

thanks

Benoit

On Jul 10, 2007, at 3:47 AM, Benoit Mathieu wrote:
> I want to use postgres to store data and large files, typically
> audio files from 100ko to 20Mo. For those files, I just need to
> store et retrieve them, in an ACID way. (I don't need search, or
> substring, or others functionnalities)
> I saw postgres offers at least 2 method : bytea column with TOAST,
> or large objects API.
>
> I wonder what are the differences of the 2 methods.
> * I found that large objects need a vacuum after delete to really
> release place. That may be handled by a trigger or automatic
> vaccum, is it right ?
> * Large objects are used via a special API available in libpq C
> client library.
> * I really care keeping my transaction fully ACID. Documentation on
> large objects doesn't explicitly say if lo_import an lo_export (and
> other primitives) are fully ACID. Some ideas ?

AFAIK large objects are ACID, at least as ACID as you can be when
dealing directly with the filesystem (lo_export). Bytea is fully ACID.

> * I going to bench insertion and read with this 2 methods.

I'd be interested to know what you find. Unless there's a notable
speed difference, I'd probably just go with bytea.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)