From: | Peter T Mount <peter(at)retep(dot)org(dot)uk> |
---|---|
To: | David Hartwig <daveh(at)insightdist(dot)com> |
Cc: | "Sergey E(dot) Levov" <serg(at)gate(dot)informika(dot)ru>, PostgreSQL Hackers List <hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] SPI procedure for removing large objects |
Date: | 1998-08-06 05:47:14 |
Message-ID: | Pine.LNX.3.96.980806064543.793G-100000@maidast.retep.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T Mount | 1998-08-06 05:57:31 | Re: [HACKERS] CVS and the backend |
Previous Message | Peter T Mount | 1998-08-06 05:45:16 | Re: [HACKERS] SPI procedure for removing large objects |