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 по дате отправления: