Re: Converting postgresql.conf parameters to kilobytes

Shridhar Daithankar <shridhar(at)frodo(dot)hserus(dot)net> writes:
> Right now following are measured in pages
> wal_buffers
> shared_buffers
> effective_cachesize
> while rest of the memory parameters are in kb. I thought being uniform would
> be good. Besides it will make it independent of page size as well.

It would probably be reasonable to change effective_cache_size, since we
really do not know what the kernel's unit of buffering is (except on
Linux, where we *do* know that it ain't 8K ;-)). Personally I'd opt for
measuring it in MB not KB, though; that would be a much more convenient
unit on modern machines. We could easily make it a float for anyone who
thinks they know the cache size to sub-MB accuracy.

As for the others, I'll side with Emerson: "a foolish consistency is the
hobgoblin of little minds". We know very well what the unit of
allocation of those is, and it's pages. There's no advantage to using
KB except making it harder to work out what's really happening. We
could measure max_connections in KB too if we had a mind to: there's
a very definite shared-mem cost per connection slot. Or the FSM
parameters, or checkpoint_segments, or max_locks_per_transaction.
The fact that they have quantifiable space costs doesn't mean that space
is the most useful way to measure them.

BTW, were you intending to convert KB to NBuffers by charging exactly 8K
per buffer, or were you intending to allow for the additional shmem
costs such as buffer headers, per-buffer LWLocks, etc? If not the
latter, then what are you really measuring? For sure it's not shared
memory size --- charging an artificial number isn't going to help anyone
who's trying to pick shared_buffers to arrive at a particular actual
shmem size. But if it is the latter then it'll become even more
impossible to tell what's really happening, and we'll be forced to
invent some way of reading out how many buffers really got allocated.

So I disagree with the premise. Measuring these things in KB is not an
improvement.

regards, tom lane