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 header: postgres=# select sizeof('10'::numeric); sizeof -------- 10 (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% faster. 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 EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings