Fujii Masao escribió: > On Sun, Mar 16, 2014 at 7:15 AM, Alexander Korotkov > <aekorot...@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. 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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
