Re: autovacuum maintenance_work_mem
| От | Josh Berkus |
|---|---|
| Тема | Re: autovacuum maintenance_work_mem |
| Дата | |
| Msg-id | 4CE2CF2B.9090603@agliodbs.com обсуждение исходный текст |
| Ответ на | Re: autovacuum maintenance_work_mem (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: autovacuum maintenance_work_mem
Re: autovacuum maintenance_work_mem |
| Список | pgsql-hackers |
On 11/16/10 9:27 AM, Robert Haas wrote:
> I'm a little skeptical about creating more memory tunables. DBAs who
> are used to previous versions of PG will find that their vacuum is now
> really slow, because they adjusted maintenance_work_mem but not this
Also, generally people who are using autovacuum don't do much manual
vacuuming, and when they do, it's easy enough to do a SET before you
issue the VACUUM statement.
So, -1 for yet another GUC.
> new parameter. If we could divide up the vacuum memory intelligently
> between the workers in some way, that would be a win. But just
> creating a different variable that controls the same thing in
> different units doesn't seem to add much.
Actually, that's not unreasonable. The difficulty with allocating
work_mem out of a pool involves concurrency, but use of maint_work_mem
is very low-concurrency; it wouldn't be that challenging to have the
autovac workers pull from a pool of preset size instead of each being
allocated the full maint_work_mem. And that would help with over/under
allocation of memory.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
В списке pgsql-hackers по дате отправления: