Shridhar Daithankar <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly