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
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
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.