On Mon, Oct 24, 2011 at 12:56 AM, Euler Taveira de Oliveira <eu...@timbira.com> wrote: > The main point of autovacuum is maintenance tasks. Currently, it executes > VACUUM and ANALYZE commands. I want to propose that we incorporate vacuumlo > functionality into it. While dealing with large objects (LO), we have lo > contrib module that helps with LO maintenance but has some limitations (does > not handle DROP TABLE and TRUNCATE cases) and vacuumlo that does an > excellent job but have to be executed outside DBMS. The proposal is to clean > up LO when autovacuum triggers VACUUM; cleanup LO routine will starts > after(?) VACUUM command. > > In a near future I want to propose that orphaned LO be cleaned up by VACUUM > but that a history for another thread... > > Comments?
I think the main reason why vacuumlo is a contrib module rather than in core is that it is just a heuristic, and it might not be what everyone wants to do. You could store a bunch of large objects in the database and use the returned OIDs to generate links that you email to users, and then when the user clicks on the link we retrieve the corresponding LO and send it to the user over HTTP. In that design, there are no tables in the database at all, yet the large objects aren't orphaned. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
