Re: Random penalties on GIN index updates?
От
Jesper Krogh
Тема
Re: Random penalties on GIN index updates?
Дата
Msg-id
4ADFE64D.1080608@krogh.cc
Ответ на
Re: Random penalties on GIN index updates? (Robert Haas)
Список
Дерево обсуждения
Random penalties on GIN index updates? jesper@krogh.cc
Re: Random penalties on GIN index updates? Tom Lane <tgl@sss.pgh.pa.us>
Re: Random penalties on GIN index updates? Jesper Krogh <jesper@krogh.cc>
Re: Random penalties on GIN index updates? Tom Lane <tgl@sss.pgh.pa.us>
Re: Random penalties on GIN index updates? Robert Haas <robertmhaas@gmail.com>
Re: Random penalties on GIN index updates? Jesper Krogh <jesper@krogh.cc>
Robert Haas wrote: > On Wed, Oct 21, 2009 at 2:35 PM, Tom Lane wrote: >> Jesper Krogh writes: >>> What I seems to miss a way to make sure som "background" application is >>> the one getting the penalty, so a random user doing a single insert >>> won't get stuck. Is that doable? >> You could force a vacuum every so often, but I don't think that will >> help the locking situation. You really need to back off work_mem --- >> 512MB is probably not a sane global value for that anyway. > > Yeah, it's hard to imagine a system where that doesn't threaten all > kinds of other bad results. I bet setting this to 4MB will make this > problem largely go away. > > Arguably we shouldn't be using work_mem to control this particular > behavior, but... I came from Xapian, where you only can have one writer process, but batching up in several GB's improved indexing performance dramatically. Lowering work_mem to 16MB gives "batches" of 11.000 documents and stall between 45 and 90s. ~ 33 docs/s -- Jesper
В списке pgsql-performance по дате отправления