On Fri, Aug 8, 2014 at 11:45 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Fri, Aug 8, 2014 at 11:43 PM, Fujii Masao <masao.fu...@gmail.com> wrote: >> On Mon, Apr 14, 2014 at 11:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Fujii Masao <masao.fu...@gmail.com> writes: >>>> On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas <robertmh...@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+kdmv2hgne...@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. Regards, ------- Sawada Masahiko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
