Simon Riggs wrote:

Proposals

1. For the first result, I suggest that we introduce some padding into
the shmem structure XLogCtlData to alleviate false sharing that may
exist between holders of WALInsertLock, WALWriteLock and info_lck. The
cost of this will be at most about 200 bytes of shmem, with a low risk
change. The benefits are hard to quantify, but we know this is an area
of high contention and we should do all we can to reduce that.
This hasn't been discussed previously, though we have seen good benefit
from avoiding false sharing in other cases, e.g. LWLOCK padding.

2. Increase NUM_BUFFER_PARTITIONS from 16 to 256 (or higher).
This has been discussed previously:
http://archives.postgresql.org/pgsql-hackers/2006-09/msg00967.php

Both of these changes are simple enough to consider for 8.3

Comments?

+1 on the idea (I can speak to the technical side). What I can say is that it is pretty much known that after 8 cores we slow down. Although 8.2 is better than any other release in this regard.

Joshua D. Drake




--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to