Re: Auto-tuning work_mem and maintenance_work_mem
От | Bruce Momjian |
---|---|
Тема | Re: Auto-tuning work_mem and maintenance_work_mem |
Дата | |
Msg-id | 20140217185241.GD18932@momjian.us обсуждение исходный текст |
Ответ на | Re: Auto-tuning work_mem and maintenance_work_mem (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Mon, Feb 17, 2014 at 07:39:47PM +0100, Andres Freund wrote: > On 2014-02-17 13:33:17 -0500, Robert Haas wrote: > > On Mon, Feb 17, 2014 at 11:33 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > >> And I still disagree with this- even in those cases. Those same untuned > > >> servers are running dirt-simple queries 90% of the time and they won't > > >> use any more memory from this, while the 10% of the queries which are > > >> more complicated will greatly improve. > > > > > > Uh. Paging. > > > > What about it? > > It's often the source of a good portion of the queries and load in web > applications. Multiple joins and more than one row... I have several > time seen stats changes or bad to-be-sorted columns cause large amounts > of memory to be used. Perhaps we should have said there was "general agreement" to increase work_mem and maintenence_work_mem by 4x, not that there was 100% agreement. It would be nice to have 100% agreement, but if we _require_ that then defaults would probably never be changed. > Anyway, I've stated my opinion that I do not think it's a good idea to > raise that particular default (while agreeing with all the others) and I > know I am in the minority, so I don't think we need to argue this out... OK, good. If you did feel there was need for more discussion, we would need to push this change to PG 9.5. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
В списке pgsql-hackers по дате отправления: