On Mar 9, 2007, at 6:42 AM, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Now regarding your restartable vacuum work. I think that stopping a
vacuum at some point and being able to restart it later is very
cool and
may get you some hot chicks, but I'm not sure it's really
Tom Lane [EMAIL PROTECTED] writes:
Er, why not just finish out the scan at the reduced I/O rate? Any sort
of abort behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples. ISTM that the vacuum ought to
just continue along its existing path at a
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Er, why not just finish out the scan at the reduced I/O rate? Any sort
of abort behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples. ISTM that the vacuum ought to
just continue along
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is everybody OK with not putting a per-tablespace worker limit?
Is everybody OK with putting per-database worker limits on a pg_database
column?
I don't think we need a new pg_database column. If it's a GUC you can
do ALTER
Galy Lee wrote:
Hi,
Alvaro Herrera wrote:
I still haven't received the magic bullet to solve the hot table
problem, but these at least means we continue doing *something*.
Can I know about what is your plan or idea for autovacuum improvement
for 8.3 now? And also what is the roadmap of
Alvaro Herrera wrote:
I don't have anything else as detailed as a plan. If you have
suggestions, I'm all ears.
Cool, thanks for the update. :) We also have some new ideas on the
improvement of autovacuum now. I will raise it up later.
Now regarding your restartable vacuum work.
Does this
Alvaro Herrera [EMAIL PROTECTED] writes:
Now regarding your restartable vacuum work. I think that stopping a
vacuum at some point and being able to restart it later is very cool and
may get you some hot chicks, but I'm not sure it's really useful.
Too true :-(
I think it makes more sense to
Tom Lane wrote:
Er, why not just finish out the scan at the reduced I/O rate? Any sort
Sometimes, you may need to vacuum large table in maintenance window and
hot table in the service time. If vacuum for hot table does not eat two
much foreground resource, then you can vacuum large table with
Alvaro Herrera [EMAIL PROTECTED] writes:
Is everybody OK with changing the autovacuum_naptime semantics?
it seems already different from 8.2, so no objection to further change.
Is everybody OK with not putting a per-tablespace worker limit?
Is everybody OK with putting per-database worker
Alvaro,
Alvaro Herrera wrote:
I still haven't received the magic bullet to solve the hot table
problem, but these at least means we continue doing *something*.
Can I know about what is your plan or idea for autovacuum improvement
for 8.3 now? And also what is the roadmap of autovacuum
On Mar 7, 2007, at 4:00 PM, Alvaro Herrera wrote:
Is everybody OK with putting per-database worker limits on a
pg_database
column?
I'm worried that we would live to regret such a limit. I can't really
see any reason to limit how many vacuums are occurring in a database,
because there's
11 matches
Mail list logo
