Re: AW: Coping with huge deferred-trigger lists

> BTW, I don't think the overwriting-smgr idea is a done deal.  We haven't
> seen any design yet for exactly how it should work.  Moreover, I'm
> really hesitant to throw away one of the fundamental design choices of
> Postgres: overwriting smgr is one of the things that got us to where we
> are today.  Before we commit to that, we ought to do some serious study
> of the alternatives.  ISTM the problem with VACUUM is not that you need
> to do a regular maintenance procedure, it's that it grabs an exclusive
> lock on the table for so long.  We could live with VACUUM if it could be
> made either incremental (do a few pages and release the lock) or capable
> of running in parallel with reader & writer transactions.  Vadim's
> still-not-integrated LAZY VACUUM code is an indicator that progress
> might be made in that direction.  (Actually, I suppose if you look at it
> in the right way, you might think that a backgroundable VACUUM *is* an
> overwriting smgr, just an asynchronous implementation of it...)

I agree overwriting storage manager is not a done deal, and I don't see
us eliminating it entirely.  We have to keep the old tuples in scope, so
I assume we would just create new tuples, and reuse the expired tuples
once they were out of scope.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026