Josh Berkus <j...@agliodbs.com> wrote: > On 10/11/2013 01:11 PM, Bruce Momjian wrote: >> In summary, I think we need to: >> >> * decide on new defaults for work_mem and maintenance_work_mem >> * add an initdb flag to allow users/packagers to set shared_bufffers? >> * add an autovacuum_work_mem setting? >> * change the default for temp_buffers? > > If we're changing defaults, bgwriter_lru_maxpages and vacuum_cost_limit > could also use a bump; those thresholds were set for servers with < 1GB > of RAM.
+1 on those. Also, I have often had to bump cpu_tuple_cost into the 0.03 to 0.05 range to get a good plan. In general, this makes the exact settings of *_page_cost less fussy, and I have hit situations where I was completely unable to get a good plan to emerge without bumping cpu_tuple_cost relative to the other cpu costs. I know that it's possible to engineer a workload that shows any particular cost adjustment to make things worse, but in real-life production environments I have never seen an increase in this range make plan choice worse. Regarding the settings which have been the center of attention for most of this thread, I have had very good luck with starting work_mem at machine RAM * 0.25 / max_connections. I get the impression that Josh regards that as too low. My guess is that he deals more with data warehouse reporting systems than I do, where larger settings are both more beneficial and less likely to cause memory exhaustion than the typical systems I've worked with. That is the big problem with auto-configuration -- it depends so much on the workload. In the long run, an admission control policy and/or adaptive configuration based on the observed workload seems like what we *really* need. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
