Re: effective_cache_size vs units

From: Shane Ambler <pgsql(at)007Marketing(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: effective_cache_size vs units
Date: 2006-12-20 04:34:55
Message-ID: 4588BD6F.8030706@007Marketing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)007Marketing(dot)com

Get Sheeky @ http://Sheeky.Biz

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2006-12-20 05:17:23 Re: Companies Contributing to Open Source
Previous Message Tom Lane 2006-12-20 04:29:24 Re: column ordering, was Re: [PATCHES] Enums patch v2