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
|
Список | 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 по дате отправления: