Re: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From August Zajonc
Subject Re: Plans for solving the VACUUM problem
Date
Msg-id 9e253b$501$1@news.tht.net
Whole thread Raw
In response to Re: Plans for solving the VACUUM problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Heck ya...

> I wonder if cache failures should be what drives the vacuum daemon to
> vacuum a table?  Sort of like, "Hey, someone is asking for free pages
> for that table.  Let's go find some!"  That may work really well.
> Another advantage of centralization is that we can record update/delete
> counters per table, helping tell vacuum where to vacuum next.  Vacuum
> roaming around looking for old tuples seems wasteful.

Counters seem like a nice addition. For example, access patterns to session
tables are almost pure UPDATE/DELETEs and a ton of them. On the other hand,
log type tables see no UPDATE/DELETE but tend to be huge in comparision. I
suspect many applications outside ours will show large disparties in the
"Vacuumability" score for different tables.

Quick question:
Using lazy vacuum, if I have two identical (at the file level) copies of a
database, run the same queries against them for a few days, then shut them
down again, are the copies still identical? Is this different than the
current behavior (ie, queries, full vacuum)?


AZ




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Plans for solving the VACUUM problem
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: Re: Plans for solving the VACUUM problem