Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-27 Thread Bruce Momjian
Josh Berkus wrote: I think the difficulty is figuring out what to get the existing workers to give us some memory when a new one comes along. You want the first worker to potentially use ALL the memory... until worker #2 arrives. Yeah, doing this would mean that you couldn't give

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Itagaki Takahiro
On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: So for the initial implementation, we could just have each worker set its local maintenance_work_mem to autovacuum_maintenance_memory / max_workers. That way there's never excessive memory usage. It sounds reasonable,

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Tom Lane
Itagaki Takahiro itagaki.takah...@gmail.com writes: On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: So for the initial implementation, we could just have each worker set its local maintenance_work_mem to autovacuum_maintenance_memory / max_workers. That way

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Heikki Linnakangas
On 16.11.2010 18:12, Alvaro Herrera wrote: Thoughts? Sounds reasonable, but you know what would be even better? Use less memory in vacuum, so that it doesn't become an issue to begin with. There was some discussion on that back in 2007

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Robert Haas
On Tue, Nov 16, 2010 at 11:12 AM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Magnus was just talking to me about having a better way of controlling memory usage on autovacuum.  Instead of each worker using up to maintenance_work_mem, which ends up as a disaster when DBA A sets to a large

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Josh Berkus
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

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Robert Haas
On Tue, Nov 16, 2010 at 1:36 PM, Josh Berkus j...@agliodbs.com wrote: 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

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Joshua D. Drake
On Tue, 2010-11-16 at 10:36 -0800, Josh Berkus wrote: 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

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Josh Berkus
I think the difficulty is figuring out what to get the existing workers to give us some memory when a new one comes along. You want the first worker to potentially use ALL the memory... until worker #2 arrives. Yeah, doing this would mean that you couldn't give worker #1 all the memory,

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Alvaro Herrera
Excerpts from Josh Berkus's message of mar nov 16 15:52:14 -0300 2010: I think the difficulty is figuring out what to get the existing workers to give us some memory when a new one comes along. You want the first worker to potentially use ALL the memory... until worker #2 arrives.

Re: [HACKERS] autovacuum maintenance_work_mem

2010-11-16 Thread Josh Berkus
Relevant to this is the question: *when* does vacuum do its memory allocation? Is memory allocation reasonably front-loaded, or does vacuum keep grabbing more RAM until it's done? All at start. That means that allocation by halves would work fine. -- --