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

From Greg Stark
Subject Re: [HACKERS] Resurrecting per-page cleaner for btree
Date
Msg-id 873bco48jm.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [HACKERS] Resurrecting per-page cleaner for btree  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Resurrecting per-page cleaner for btree
List pgsql-patches
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.

The case that perhaps hasn't been made is for whether retail vacuum is the
best solution. The only other candidate that I've seen proposed (many many
times) is some form of segregating the older tuples a la Oracle.

That doesn't mean retail vacuuming is a good idea. It may just be that we
haven't thought of a the best option yet. But it also may be that retail
vacuuming or some kind of rollback segment is just the least bad idea.

--
greg

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: LDAP lookup of connection parameters
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Patch for VS.Net 2005's strxfrm() bug