Re: Automatic free space map filling

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: Automatic free space map filling
Дата
Msg-id 87ek1lq8cl.fsf@wolfe.cbbrowne.com
обсуждение исходный текст
Ответ на Automatic free space map filling  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Automatic free space map filling  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Automatic free space map filling  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Automatic free space map filling  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Centuries ago, Nostradamus foresaw when tgl@sss.pgh.pa.us (Tom Lane) would write:
> I thought we had sufficiently destroyed that "reuse a tuple" meme
> yesterday.  You can't do that: there are too many aspects of the system
> design that are predicated on the assumption that dead tuples do not
> come back to life.

This discussion needs to come up again in October when the zombie
movies come out :-).

> That's the other problem: it's not apparent why pushing work from
> vacuum back into foreground processing is a good idea.  Especially
> not why retail vacuuming of individual tuples will be better than
> wholesale.

What is unclear to me in the discussion is whether or not this is
invalidating the item on the TODO list...

-------------------
Create a bitmap of pages that need vacuuming

Instead of sequentially scanning the entire table, have the background
writer or some other process record pages that have expired rows, then
VACUUM can look at just those pages rather than the entire table. In
the event of a system crash, the bitmap would probably be
invalidated. One complexity is that index entries still have to be
vacuumed, and doing this without an index scan (by using the heap
values to find the index entry) might be slow and unreliable,
especially for user-defined index functions.
-------------------

It strikes me as a non-starter to draw vacuum work directly into the
foreground; there is a *clear* loss in that the death of the tuple
can't actually take place at that point, due to MVCC and the fact that
it is likely that other transactions will be present, keeping the
tuple from being destroyed.

But it would *seem* attractive to do what is in the TODO, above.
Alas, the user defined index functions make cleanout of indexes much
more troublesome :-(.  But what's in the TODO is still "wholesale,"
albeit involving more targetted selling than the usual Kirby VACUUM
:-).
-- 
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxdatabases.info/info/rdbms.html
Rules  of the  Evil Overlord  #140. "I  will instruct  my  guards when
checking a cell that appears empty to look for the chamber pot. If the
chamber pot is still there, then the prisoner has escaped and they may
enter and  search for  clues. If  the chamber pot  is not  there, then
either the prisoner is perched above the lintel waiting to strike them
with it or else he decided to  take it as a souvenir (in which case he
is  obviously deeply  disturbed  and poses  no  threat).  Either  way,
there's no point in entering." <http://www.eviloverlord.com/>


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

Предыдущее
От: seth.m.green@gmail.com
Дата:
Сообщение: ACCESS EXCLUSIVE LOCK
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ACCESS EXCLUSIVE LOCK