Ü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 <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
