I have two tables (table1
, table2
) in a Postgres 9.1 database. Both having oid type. Each table 1 million records. And pg_largeobject
table size is around 40GB. I have removed 0.9 million records from each table, and executed the below command.
vacuum full analyze table1;
vacuum full analyze table2;
Still no change in pg_largeobject
table size (auto vacuum is enabled)
Do I need to execute above command to pg_largeobject
table too? Will it impact anything?
Best Answer
You can run that, no problem:
Might even remove some dead rows. Details:
But it's probably not going to solve your actual problem.
When using the large object facility of Postgres, large objects ("blob": binary large object) themselves are broken up in chuncks of binary data stored in the system table
pg_largeobject
. The PK consists of two columns(loid, pageno)
,loid
is theoid
that is used to refer to the blob in user table(s). The same blob can be referenced by OID many times.Deleting rows in user tables does not remove the blob. For one, the same blob might be referenced more than one times. It is your responsibility to keep track and actually delete "unlinked" blobs yourself. One way would be to use
lo_unlink()
:Since you already deleted rows with the
oid
reference, you need to be a bit more creative to identify unlinked blobs. Assuming you do not reference blobs from any other places, you can use this query to fix:You need to be superuser to access
pg_largeobject
directly. Assuming the column name intable1
andtable2
isoid
. Simpler query based onpg_largeobject_metadata
in Postgres 9.3 or later (like @Daniel commented):pg_largeobject_metadata
is publicly readable. But I don't see the OID of the blob in the system table in versions before pg 9.3 (incl. pg 9.1) - at least not in the manual, I don't have an old version to test right now. So you probably must use my first query.Compare before and after:
You might run
VACUUM FULL
now, and test again:You'll be interested in the additional module
lo
, that's available for Postgres 9.1. The manual has an accurate description for your problem:Bold emphasis mine. The module offers a solution, too:
For use cases where each blob is referenced exactly once in your whole DB.
And obviously also (like @Daniel mentioned)
vacuumlo
: