On Mon, Mar 17, 2014 at 10:44 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Fujii Masao escribió:
>> On Sun, Mar 16, 2014 at 7:15 AM, Alexander Korotkov
>> <aekorotkov@gmail.com> wrote:
>
>> >> That could be optimized, but I figured we can live with it, thanks to the
>> >> fastupdate feature. Fastupdate allows amortizing that cost over several
>> >> insertions. But of course, you explicitly disabled that...
>> >
>> > Let me know if you want me to write patch addressing this issue.
>>
>> Yeah, I really want you to address this problem! That's definitely useful
>> for every users disabling FASTUPDATE option for some reasons.
>
> Users that disable FASTUPDATE, in my experience, do so because their
> stock work_mem is way too high and GIN searches become too slow due to
> having to scan too large a list.
Yes. Another reason that I've heard from users so far is that
the size of GIN index with FASTUPDATE=off is likely to be smaller
than that with FASTUPDATE=on.
> I think it might make sense to invest
> a modest amount of time in getting FASTUPDATE to be sized completely
> differently from today -- perhaps base it on a hardcoded factor of
> BLCKSZ, rather than work_mem. Or, if we really need to make it
> configurable, then let it have its own parameter.
I prefer to have the parameter. When users create multiple GIN indexes
for various uses, they might want to use different thresholds of the pending
list for each index. So, GIN index parameter might be better than GUC one.
Regards,
--
Fujii Masao