35.2. Implementation Features
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.