Re: [HACKERS] SPI procedure for removing large objects

On Wed, 5 Aug 1998, David Hartwig wrote:

> Peter T Mount wrote:
>
> > On Wed, 5 Aug 1998, David Hartwig wrote:
> >
> > > Peter,
> > >
> > > I have just finished up some other stuff in the backend, and I was
> > > wondering what to do next. My personal list include a cleanup of the lo
> > > type. Specifically:
> > >
> > > 1. Assign a fixed OID to the LO type so that attributes of this type
> > > can easily be identified.
> > >
> > > 2. Write a VACUUM LO procedure.
> > >
> > > 3. Extend/verify the existing internal lo functions to work with the
> > > new type.
> > >
> > > I know that more can/should be done in this area, but I only have so much
> > > time. I am aware the you have done some work on this in the contrib area.
> > > Were you planning on handling any (or all) of these issues as part of the
> > > 6.4 base release? I will gladly move on to something else.
> >
> > I claimed the parts of the TODO list that deal with these issues a few
> > weeks ago.
>
> I will move on to something else unless their is something I can assist you
> with.
>
> > Since then, I've tried several solutions (the one in contrib
>
> > was an attempt that uses triggers. It works but has holes - like DROP
> > TABLE doesnt fire a trigger).
> >
>
> Actually, the trigger is still worth having in the bag-o-tricks. It can keep
> numerous additions and removals of tuples with LOs from filling up the disk
> before the vacuum gets executed.

I think for small tables, then relying on VACUUM LO would be enough.
However, the trigger would be a viable option for DBA's when either the
database is huge, or has a lot of traffic.

> > The method I think is best is the vacuum procedure. Now, I have here the
> > basic outline for it, and how it interacts with the existing system using
> > oid's, but currently I can't test it as postgresql is still broken (for
> > me).

--
Peter T Mount peter(at)retep(dot)org(dot)uk or petermount(at)earthling(dot)net
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres