Bruce Momjian <[EMAIL PROTECTED]> writes:

> Gregory Stark wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Sure, this helps with CHAR(1) but there were plen
> OK.  

Ooops, sorry, I guess I sent that before I was finished editing it. I'm glad
you could divine what I meant because I'm not entirely sure myself :)

> Well, if you are using TEXT, it is hard to say you are worried about
> storage size.  I can't imagine many one-byte values are stored in TEXT.

Sure, what about "Middle name or initial". Or "Apartment Number". Or for that
matter "Drive Name" on a windows box. Just because the user doesn't want to
enforce a limit on the field doesn't mean the data will always be so large.

>> Part of the reason I think the smallfoo data types may be a bright idea in
>> their own right is that the datatypes might be able to do clever things about
>> their internal storage. For instance, smallnumeric could use base 100 where
>> largenumeric uses base 10000.
> I hardly think modifying the numeric routines to do a two different
> bases is worth it.  

It doesn't actually require any modification, it's already a #define. It may
be worth doing the work to make it a run-time parameter so we don't need to
recompile the functions twice.

I'm pretty sure it's worthwhile as far as space conservation goes. a datum
holding a value like "10" currently takes 10 bytes including the length

postgres=# select sizeof('10'::numeric);
(1 row)

That would go down to 7 bytes with a 1-byte length header. And down to 4 bytes
with base 100. Ie, reading a table full of small numeric values would be 75%

With some clever hacking I think we could get it to go down to a single byte
with no length header just like ascii characters for integers under 128. But
that's a separate little side project.

  Gregory Stark

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to