Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
От | Fujii Masao |
---|---|
Тема | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index |
Дата | |
Msg-id | CAHGQGwEffKKoOZ-4EkaK414zzTf3m26R=koHt+nQh0wqoUKQpw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index (Sawada Masahiko <sawada.mshk@gmail.com>) |
Ответы |
Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re:
HEAD seems to generate larger WAL regarding GIN index
|
Список | pgsql-hackers |
On Sat, Aug 16, 2014 at 4:23 PM, Sawada Masahiko <sawada.mshk@gmail.com> wrote: > On Fri, Aug 8, 2014 at 11:45 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Fri, Aug 8, 2014 at 11:43 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >>> On Mon, Apr 14, 2014 at 11:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> 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. >>> >>> The attached patch introduces the GIN index storage parameter >>> "PENDING_LIST_CLEANUP_SIZE" which specifies the maximum size of >>> GIN pending list. If it's not set, work_mem is used as that maximum size, >>> instead. So this patch doesn't break the existing application which >>> currently uses work_mem as the threshold of cleanup operation of >>> the pending list. It has only not to set PENDING_LIST_CLEANUP_SIZE. >>> >>> This is an index storage parameter, and allows us to specify each >>> threshold per GIN index. So, for example, we can increase the threshold >>> only for the GIN index which can be updated heavily, and decrease it otherwise. >>> >>> This patch uses another patch that I proposed (*1) as an infrastructure. >>> Please apply that infrastructure patch first if you apply this patch. >>> >>> (*1) >>> http://www.postgresql.org/message-id/CAHGQGwEanQ_e8WLHL25=bm_8Z5zkyZw0K0yiR+kdMV2HgnE9FQ@mail.gmail.com >>> >>> Regards, >>> >>> -- >>> Fujii Masao >> >> Sorry, I forgot to attached the patch.... This time, attached. >> > > I think that this patch should be rebased. > It contains garbage code. Thanks for reviewing the patch! ISTM that I failed to make the patch from my git repository... Attached is the rebased version. Regards, -- Fujii Masao
Вложения
В списке pgsql-hackers по дате отправления: