On Fri, Jun 23, 2006 at 02:00:38PM -0400, Joseph Shraibman wrote:
> I like to make sure the vacuum takes place during off peak times, which
> is why I don't use autovacuum.
FWIW, now that there's vacuum_cost_delay that's usually not a very good
strategy. If you have anywhere close to enough load
The verbose output shows the table being vacuumed last. Maybe it
changed after 8.0
Greg Stark wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
My RFE: When vacuuming a table, pg should try to vacuum the primary key
first. If that results in 0 recovered entries, then assume the table has no
up
Jim Nasby <[EMAIL PROTECTED]> writes:
> > My RFE: When vacuuming a table, pg should try to vacuum the primary key
> > first. If that results in 0 recovered entries, then assume the table has
> > no
> > updates/deletes and skip the rest of that table.
That makes no sense. Vacuum starts by sc
I like to make sure the vacuum takes place during off peak times, which
is why I don't use autovacuum.
Jim Nasby wrote:
On Jun 22, 2006, at 7:12 PM, Joseph Shraibman wrote:
I'm running a 8.0 database. I have a very large log table that is
rarely updated or deleted from. The nightly vacuum do
On Jun 22, 2006, at 7:12 PM, Joseph Shraibman wrote:
I'm running a 8.0 database. I have a very large log table that is
rarely updated or deleted from. The nightly vacuum does not know
this, and spends a lot of time on it, and all its indexes.
My RFE: When vacuuming a table, pg should try t
I'm running a 8.0 database. I have a very large log table that is
rarely updated or deleted from. The nightly vacuum does not know this,
and spends a lot of time on it, and all its indexes.
My RFE: When vacuuming a table, pg should try to vacuum the primary key
first. If that results in 0 r
