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?
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
