Re: using a lot of maintenance_work_mem
| От | Bruce Momjian |
|---|---|
| Тема | Re: using a lot of maintenance_work_mem |
| Дата | |
| Msg-id | 201102201432.p1KEW2s24368@momjian.us обсуждение исходный текст |
| Ответ на | Re: using a lot of maintenance_work_mem (Devrim GÜNDÜZ <devrim@gunduz.org>) |
| Ответы |
Re: using a lot of maintenance_work_mem
Re: using a lot of maintenance_work_mem |
| Список | pgsql-hackers |
Devrim G�ND�Z wrote: > On Wed, 2011-02-16 at 23:24 +0200, Peter Eisentraut wrote: > > > > > But before expending time on that, I'd want to see some evidence > > that > > > it's actually helpful for production situations. I'm a bit dubious > > > that you're going to gain much here. > > > > If you want to build an index on a 500GB table and you have 1TB RAM, > > then being able to use >>1GB maintenance_work_mem can only be good, > > no? > > That would also probably speed up Slony (or similar) replication engines > in initial replication phase. I know that I had to wait a lot while > creating big indexes on a machine which had enough ram. Well, I figure it will be hard to allow larger maximums, but can we make the GUC variable maximums be more realistic? Right now it is MAX_KILOBYTES (INT_MAX). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: