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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026