Am 03.12.2011 18:39, schrieb Tom Lane:
The long and the short of it is those numbers aren't meant to be exact. If they were, we'd have to complicate the table to distinguish 32 vs 64 bit and possibly other factors, and we'd have to remember to re-measure the values after any code change, neither of which seems worth the trouble. Please note that the table itself says that (a) the values are approximate, and (b) nobody has bothered to update the numbers since 8.3. Personally, I'm thrilled if you're seeing a discrepancy of only 1.25%.
Understood. Btw, the 1.25% did not refer to the discrepancy between calculated and measured value, but to the memory overhead Tomas Vondra measured for the shared buffer pool, while I measured an overhead of about 2.5%, which should be also expected according to the docs.
Another thing that's a bit confusing in Table 17.2 is that it is not immediately clear what size the shared disk buffers and wal buffers have when shared_buffers and wal_buffers are specified in memory units, not as integers as the table implies.
The answer is, as I found out, in order to get the "real" values for shared_buffers and wal_buffers, the memory values must be divided by block_size resp. wal_block_size; the formula then stays the same.
-- Christoph -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
