Ühel kenal päeval, K, 2006-07-26 kell 23:02, kirjutas Martijn van
> 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

Reply via email to