Re: [HACKERS] Resurrecting per-page cleaner for btree - Mailing list pgsql-patches

From Martijn van Oosterhout
Subject Re: [HACKERS] Resurrecting per-page cleaner for btree
Date
Msg-id 20060726210238.GD32377@svana.org
Whole thread Raw
In response to Re: [HACKERS] Resurrecting per-page cleaner for btree  (Greg Stark <gsstark@mit.edu>)
Responses Re: [HACKERS] Resurrecting per-page cleaner for btree
List pgsql-patches
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...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to user level
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to