From: | "August Zajonc" <augustz(at)bigfoot(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Plans for solving the VACUUM problem |
Date: | 2001-05-18 03:31:54 |
Message-ID: | 9e253b$501$1@news.tht.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2001-05-18 03:50:40 | Re: Re: Plans for solving the VACUUM problem |
Previous Message | Bruce Momjian | 2001-05-18 02:27:51 | Re: Plans for solving the VACUUM problem |