Re: Plans for solving the VACUUM problem

Поиск
Список
Период
Сортировка
От Vadim Mikheev
Тема Re: Plans for solving the VACUUM problem
Дата
Msg-id 004301c0e1a1$d1e7fd80$4879583f@sectorbase.com
обсуждение исходный текст
Ответ на Re: Plans for solving the VACUUM problem  (The Hermit Hacker <scrappy@hub.org>)
Ответы Re: Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> 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?

It probably will not cause more IO than vacuum does right now.
But unfortunately it will not reduce that IO. Cleanup work will be spreaded
in time and users will not experience long lockouts but average impact
on overall system throughput will be same (or maybe higher).
My point is that we'll need in dynamic cleanup anyway and UNDO is
what should be implemented for dynamic cleanup of aborted changes.
Plus UNDO gives us natural implementation of savepoints and some
abilities in transaction IDs management, which we may use or not
(though, 4. - pg_log size management - is really good thing).

Vadim




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

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