are you sure you have autovacuum configured properly, so posting lists don't
grow too much. It's true, that concurrency of posting lists isn't good, since
they all appended.

On Thu, 15 Sep 2011, Jesper Krogh wrote:

Hi List.

This is just an "observation" I'll try to reproduce it in a test set later.

I've been trying to performancetune a database system which does
a lot of updates on GIN indexes. I currently have 24 workers running
executing quite cpu-intensive stored procedures that helps generate
the body for the gin index (full-text-search).

The system is all memory resident for the data that gets computed on
and there is a 1GB BBWC before data hits the disk-system. The iowait
is 5-10% while running.

The system is nearly twice as fast with fastupdate=off as with fastupdate=on.
Benchmark done on a 9.0.latest

System AMD Opteron, 4x12 cores @ 2.2ghz, 128GB memory.

It is probably not as surprising as it may seem, since the "fastupdate" is
about batching up in a queue for processing later, but when the "later"
arrives, concurrency seems to stop.

Is it worth a documentation comment?

Oleg Bartunov, Research Scientist, Head of AstroNet (,
Sternberg Astronomical Institute, Moscow University, Russia
phone: +007(495)939-16-83, +007(495)939-23-83

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to