Re: [HACKERS] SPI procedure for removing large objects
От | Peter T Mount |
---|---|
Тема | Re: [HACKERS] SPI procedure for removing large objects |
Дата | |
Msg-id | Pine.LNX.3.96.980806064543.793G-100000@maidast.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] SPI procedure for removing large objects (David Hartwig <daveh@insightdist.com>) |
Список | 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@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
В списке pgsql-hackers по дате отправления: