Re: Minimally avoiding Transaction Wraparound in VLDBs
От | Gavin Sherry |
---|---|
Тема | Re: Minimally avoiding Transaction Wraparound in VLDBs |
Дата | |
Msg-id | Pine.LNX.4.58.0509011316530.6411@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: Minimally avoiding Transaction Wraparound in VLDBs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Minimally avoiding Transaction Wraparound in VLDBs
|
Список | pgsql-hackers |
On Wed, 31 Aug 2005, Tom Lane wrote: > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > >> I really really do not like proposals to introduce still another kind > >> of VACUUM. We have too many already; any casual glance through the > >> archives will show that most PG users don't have a grip on when to use > >> VACUUM FULL vs VACUUM. Throwing in some more types will make that > >> problem exponentially worse. > > > Yes, but if they're all under the control of autovacuum, then users > > don't have to worry... > > Well, if the proposal comes packaged with an algorithm by which > autovacuum will use it, that's a different story. What's sticking in > my craw about this proposal is really that it's assuming detailed manual > management of vacuuming, which is exactly the thing we've been sweating > to get rid of. > > BTW ... the original Berkeley papers on Postgres make frequent reference > to a "vacuum daemon", which seems to be essentially what we're trying to > build with autovacuum. Does anyone know if the Berkeley implementation > ever actually had auto vacuuming, or was that all handwaving? If it did > exist, why was it removed? Well, from my reading of some of the early papers, VACUUM was kind of different to what it is now. The idea was that expired data would be moved out the heap and stored else where. A timetravel mechanism could be used to see previous versions of the row. It makes sense that they would manage this with a daemon, but I never saw one. Mind, I wasn't looking for one. Thanks, Gavin
В списке pgsql-hackers по дате отправления: