Re: HEAD seems to generate larger WAL regarding GIN index

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: HEAD seems to generate larger WAL regarding GIN index
Date: 2014-03-17 13:44:56
Message-ID: 20140317134456.GL6899@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii Masao escribió:
> On Sun, Mar 16, 2014 at 7:15 AM, Alexander Korotkov
> <aekorotkov(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-17 13:47:43 Re: pg_dump without explicit table locking
Previous Message Mitsumasa KONDO 2014-03-17 13:44:38 Re: [RFC] What should we do for reliable WAL archiving?