Re: Plans for solving the VACUUM problem

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: Plans for solving the VACUUM problem
Дата
Msg-id Pine.BSF.4.33.0105201826150.3057-100000@mobile.hub.org
обсуждение исходный текст
Ответ на Re: Plans for solving the VACUUM problem  ("Vadim Mikheev" <vmikheev@sectorbase.com>)
Ответы Re: Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, 20 May 2001, Vadim Mikheev wrote:

> > >> 1. Space reclamation via UNDO doesn't excite me a whole lot, if we can
> > >> make lightweight VACUUM work well.
> >
> > > Sorry, but I'm going to consider background vacuum as temporary solution
> > > only. As I've already pointed, original PG authors finally became
> > > disillusioned with the same approach.
> >
> > How could they become disillusioned with it, when they never tried it?
> > I know of no evidence that any version of PG has had backgroundable
> > (non-blocking-to-other-transactions) VACUUM, still less within-relation
> > space recycling.  They may have become disillusioned with the form of
> > VACUUM that they actually had (ie, the same one we've inherited) --- but
> > please don't call that "the same approach" I'm proposing.
>
> Pre-Postgres'95 (original) versions had vacuum daemon running in
> background. I don't know if that vacuum shrinked relations or not
> (there was no shrinking in '95 version), I know that daemon had to
> do some extra work in moving old tuples to archival storage, but
> anyway as you can read in old papers in the case of consistent heavy
> load daemon was not able to cleanup storage fast enough. And the
> reason is obvious - no matter how optimized your daemon will be
> (in regard to blocking other transactions etc), it will have to
> perform huge amount of IO just to find space available for reclaiming.
>
> > Certainly, doing VACUUM this way is an experiment that may fail, or may
> > require further work before it really works well. But I'd appreciate it
> > if you wouldn't prejudge the results of the experiment.
>
> Why not, Tom? Why shouldn't I say my opinion?
> Last summer your comment about WAL, may experiment that time, was that
> it will save just a few fsyncs. It was your right to make prejudment,
> what's wrong with my rights? And you appealed to old papers as well, BTW.

If its an "experiment", shouldn't it be done outside of the main source
tree, with adequate testing in a high load situation, with a patch
released to the community for further testing/comments, before it is added
to the source tree?  From reading Vadim's comment above (re:
pre-Postgres95), this daemonized approach would cause a high I/O load on
the server in a situation where there are *alot* of UPDATE/DELETEs
happening to the database, which should be easily recreatable, no?  Or,
Vadim, am I misundertanding?




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Plans for solving the VACUUM problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Plans for solving the VACUUM problem