The large object implementation breaks large objects up into
"chunks" and stores the chunks in rows
in the database. A B-tree index guarantees fast searches for the
correct chunk number when doing random access reads and
writes.

The chunks stored for a large object do not have to be
contiguous. For example, if an application opens a new large
object, seeks to offset 1000000, and writes a few bytes there,
this does not result in allocation of 1000000 bytes worth of
storage; only of chunks covering the range of data bytes actually
written. A read operation will, however, read out zeroes for any
unallocated locations preceding the last existing chunk. This
corresponds to the common behavior of "sparsely allocated" files in Unix file systems.

As of PostgreSQL 9.0, large
objects have an owner and a set of access permissions, which can
be managed using GRANT and REVOKE. SELECT
privileges are required to read a large object, and UPDATE privileges are required to write or
truncate it. Only the large object's owner (or a database
superuser) can delete, comment on, or change the owner of a large
object. To adjust this behavior for compatibility with prior
releases, see the lo_compat_privileges
run-time parameter.