Re: HEAD seems to generate larger WAL regarding GIN index
От | Tom Lane |
---|---|
Тема | Re: HEAD seems to generate larger WAL regarding GIN index |
Дата | |
Msg-id | 13399.1397486449@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: HEAD seems to generate larger WAL regarding GIN index (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
Fujii Masao <masao.fujii@gmail.com> writes: > On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> Should we try to install some hack around fastupdate for 9.4? I fear >> the divergence between reasonable values of work_mem and reasonable >> sizes for that list is only going to continue to get bigger. I'm sure >> there's somebody out there who has work_mem = 16GB, and stuff like >> 263865a48973767ce8ed7b7788059a38a24a9f37 is only going to increase the >> appeal of large values. > Controlling the threshold of the size of pending list only by GUC doesn't > seem reasonable. Users may want to increase the threshold only for the > GIN index which can be updated heavily, and decrease it otherwise. So > I think that it's better to add new storage parameter for GIN index to control > the threshold, or both storage parameter and GUC. Yeah, -1 for a GUC. A GIN-index-specific storage parameter seems more appropriate. Or we could just hard-wire some maximum limit. Is it really likely that users would trouble to set such a parameter if it existed? regards, tom lane
В списке pgsql-hackers по дате отправления: