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