From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Joris Dobbelsteen <Joris(at)familiedobbelsteen(dot)nl> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Autovacuum Improvements |
Date: | 2007-01-09 21:18:02 |
Message-ID: | 20070109211802.GD11064@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joris Dobbelsteen wrote:
> Now we have at least one different model, lets mix in other captures and
> situations. So it cannot be done with only YOUR data, I fully agree.
> But if you have sufficient data you can find the generalization of the
> model to make it work (resonable) in sufficient situations.
> Of course models need time to evolve, but so does the implementation
> currently at a slow rate. From do it yourself, to scripts, to the
> current autovacuum integration (which is good). From doing all tables
> sequentially to having some intelligence by update thresholds, to what
> will be next.
>
> I think you should better solve the problem is this ways, as models are
> relative easy to compare compared to arguments without
> analyzable/simulatible data.
To be frank, I'm not sure I understand what you're saying here. I'm
sure more analysis is good; that's easy to agree with.
However, I don't want to be trapped in a design that's too hard to
implement, or too hard for DBAs to manage. There have been proposals to
add these knobs:
- maximum number of simultaneous processes (and make it more than 1)
- times of day on which to change parameters (i.e. disable vacuum
altogether, or make it more agressive or less)
Do you have further ideas?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | guillermo arias | 2007-01-09 21:23:49 | PGPASS.CONF ¿is there a way to protect it? |
Previous Message | Jonathan Hedstrom | 2007-01-09 21:13:27 | Re: ERROR: invalid memory alloc request size, and others |