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 c
"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 a
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 usef
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:
> 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 sen
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
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 road
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
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 no
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 improve
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
Hackers,
I want to propose some very simple changes to autovacuum in order to
move forward (a bit):
1. autovacuum_naptime semantics
2. limiting the number of workers: global, per database, per tablespace?
I still haven't received the magic bullet to solve the hot table
problem, but these at leas
12 matches
Mail list logo
