Re: Have vacuum emit a warning when it runs out of maintenance_work_mem
От | Heikki Linnakangas |
---|---|
Тема | Re: Have vacuum emit a warning when it runs out of maintenance_work_mem |
Дата | |
Msg-id | 46460E28.8060602@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Have vacuum emit a warning when it runs out of maintenance_work_mem ("Jim C. Nasby" <jim@nasby.net>) |
Ответы |
Re: Have vacuum emit a warning when it runs out of maintenance_work_mem
Re: Have vacuum emit a warning when it runs out of maintenance_work_mem |
Список | pgsql-patches |
Or we could switch to a more compact representation of the dead tuples, and not need such a big maintenance_work_mem in the first place. Jim C. Nasby wrote: > On Fri, May 11, 2007 at 10:18:30PM -0400, Robert Treat wrote: >> On Wednesday 09 May 2007 19:41, Guillaume Smet wrote: >>> On 5/9/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Jim Nasby <decibel@decibel.org> writes: >>>>> Any time this happens it's generally a nasty surprise for users. >>>> Really? Running out of work memory is expected on large tables. >>> Sure. Perhaps we should find a better error message but it's an >>> interesting information. Personnaly, I try to choose a sane value >>> depending on my database but I'm never sure it's really sufficient or >>> if I added 100MB it would have made a real difference. > > Unfortunately, a lot of users aren't as knowledgeable as folks here, > that's why I made it a warning and gave it a hint. But if people think > that's too high a level we can change it to something lower... > >> If we were going to implement this (and I'm a tad skeptical as well), wouldn't >> it be better if the warning occured at the end of vacuum, and told you how >> much memory was actually needed, so you'd know what maintainence_work_mem >> should be. > > Maybe... the problem is that for really large tables you simply won't > have a choice; it will have to fall to disk. So I think we'd have to > keep per-table warnings, unless you've got an idea for how we could > account for tables that wouldn't reasonably fit? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: