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

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: [PATCHES] Resurrecting per-page cleaner for btree
Дата
Msg-id 1153949357.2928.32.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: [PATCHES] Resurrecting per-page cleaner for btree  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: [PATCHES] Resurrecting per-page cleaner for btree  (Jim Nasby <jnasby@pervasive.com>)
Список pgsql-hackers
Ühel kenal päeval, K, 2006-07-26 kell 23:02, kirjutas Martijn van
Oosterhout:
> On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote:
> > 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.
>
> I thought the suggested solution for that was the dead space map. That
> way vacuum can ignore parts of the table that havn't changed...

It can ignore parts of the *table* but still has to scan full *indexes*.

--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com


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

Предыдущее
От: Darcy Buskermolen
Дата:
Сообщение: Re: [PATCHES] [PATCH] Provide 8-byte transaction IDs to user level
Следующее
От: "Bort, Paul"
Дата:
Сообщение: Re: GUC with units, details