Re: effective_cache_size vs units

Поиск
Список
Период
Сортировка
От Shane Ambler
Тема Re: effective_cache_size vs units
Дата
Msg-id 4588BD6F.8030706@007Marketing.com
обсуждение исходный текст
Ответ на Re: effective_cache_size vs units  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Nor do I believe that we'd ever accept a future patch that made
>> the distinction between "kb" and "kB" significant --- if you think
>> people are confused now, just imagine what would happen then.
> 
> As I said elsewhere, I'd imagine future functionality like a units-aware 
> data type, which has been talked about several times, and then this 
> would be really bad.
> 

Most if not all of us here with computer knowledge (particularly at the 
programming level) know the difference between capital and lowercase 
memory/data size abbreviations.

Case insensitive size measurements don't matter if you actually know 
what the abbreviations mean.

The case where case matters ;-) is b and B (bits and Bytes for those 
that don't know the diff)

And if you don't know the difference between m and M - one is a portion 
of and the other is a multiple of. So mB would technically mean 0.001 of 
a byte. I'd like to see you allocate that!!

As is the case of many english words - the context of the usage makes a 
big difference in the interpretation.

Given that the purpose of the effective_cache_size setting (and similar) 
is to specify the amount of memory you want allocated/limited to, then 
that context allows you to assume that all unit abbreviations are 
specifying bytes/kilobytes/megabytes/gigabytes and not 
bits/kilobits/millibits/millibytes etc


As for the future - well, TB is getting more common, petabytes of 
storage has been talked about, 64bit systems can access exabytes of ram. 
Next would be zettabytes and yottabytes.

Unless we start a roman numeral system for amounts bigger than that then 
I seriously doubt that we will hit any confusion with future usage. (and 
I doubt in our lifetimes) Though I suppose with storage expansion rates 
increasing the way they have the last few years we may be using 
yottabyte hard drives on our 256bit systems with 512 zettabytes of ram 
in about 15 years ;-)

That might make it around the end of life for the 8.0 branch so maybe we 
need to consider handling these future storage needs soon?

Maybe in 40 years we will all retire with mega-yotta-byte drives in our 
pda watches?


As for units aware datatypes - what options are available will need to 
be decided at implementation time. Will we allow megabit (Mb) size 
allocations or only megabyte? I would say bits would be clearly 
specified as such (bit instead of b)



Let's skip any flame wars on this and concentrate on the humorous future 
storage sizes.


-- 

Shane Ambler
pgSQL@007Marketing.com

Get Sheeky @ http://Sheeky.Biz


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: column ordering, was Re: [PATCHES] Enums patch v2
Следующее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: Companies Contributing to Open Source