Jesper,
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.
Oleg
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?
Regards,
Oleg
_
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: o...@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
