Re: [HACKERS] Resurrecting per-page cleaner for btree

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [HACKERS] Resurrecting per-page cleaner for btree
Дата
Msg-id 873bco48jm.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Resurrecting per-page cleaner for btree  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Resurrecting per-page cleaner for btree  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-patches
Tom Lane <tgl@sss.pgh.pa.us> writes:

> So far, the case hasn't been made for retail vacuum even ignoring the
> not-so-immutable-function risk.

Well the desire for it comes from a very well established need for dealing
with extremely large tales with relatively small hot spots. The basic problem
being that currently the cost of vacuum is proportional to the size of the
table rather than the amount of dead space. There's no link between those
variables (at least in one direction) and any time they're far out of whack it
means excruciating pain for the DBA.

The case that perhaps hasn't been made is for whether retail vacuum is the
best solution. The only other candidate that I've seen proposed (many many
times) is some form of segregating the older tuples a la Oracle.

That doesn't mean retail vacuuming is a good idea. It may just be that we
haven't thought of a the best option yet. But it also may be that retail
vacuuming or some kind of rollback segment is just the least bad idea.

--
greg

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: LDAP lookup of connection parameters
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Patch for VS.Net 2005's strxfrm() bug