Re: Reducing the overhead of NUMERIC data

On Tue, Nov 01, 2005 at 05:40:35PM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > You are proposing a fourth type, say VARLENA2 which looks a lot like a
> > verlena but it's not. I think the shear volume of code that would need
> > to be checked is huge. Also, things like pg_attribute would need
> > changing because you have to represent this new state somehow.
>
> It wouldn't be an impossible amount of code --- for precedent see back
> when we made cstring into a full-fledged datatype (cstring is already
> a fourth option in your list BTW). That patch wasn't all that large IIRC.
> The issue in my mind is the performance implications of adding an
> additional case to places that are already hotspots. There were
> compelling functional reasons to pay that price to make cstring work,
> but "save 2 bytes per numeric" doesn't seem like it rises to that level.
> Maybe if we had a few other datatypes that could also use the feature.
> [ thinks... ] inet/cidr comes to mind but I don't see any others.
> The case seems a bit weak :-(

Would varchar(255) fit into that case? There's a heck of a lot of people
who use that as "well, dunno how big this is so I'll just use 255". A
better use case would be places where you know you'll only need 10-20
characters; saving 2 bytes in those cases would likely be worth it. This
would work for char as well (and given that people are probably not in
the habit of defining very large char's it would probably be even more
useful there).

Of course that means either yet another varchar/char type, or we have
some automatic cut-over for fields defined over a certain size...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461