From: | Christoph Zwerschke <cito(at)online(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Shared memory usage in PostgreSQL 9.1 |
Date: | 2011-12-03 18:51:04 |
Message-ID: | 4EDA6F98.8020705@online.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Lou Picciano | 2011-12-03 18:51:31 | Re: returning results from plsql function to plpythonu function |
Previous Message | Christoph Zwerschke | 2011-12-03 18:23:57 | Re: Shared memory usage in PostgreSQL 9.1 |