Mark Butler <butlerm@middle.net> writes:
> I noticed the storage format for the numeric type is rather inefficient:
> ...
> A zero value uses two bytes total in Oracle, where in the current version of
> PostgreSQL it uses ten bytes.
Yawn ... given row overhead, alignment padding, etc, this is not nearly
as big a deal as you make it ...
> Is there a reason why varlen has to be an int32?
Yes. That's what all varlena types use.
> The other three fields could be int8 as well.
If we were willing to restrict numeric values to a much tighter range,
perhaps so. I rather like a numeric type that can handle ranges wider
than double precision, however.
> Having a reasonable maximum precision would allow a fixed
> length internal representation which make processing *much* faster* by using
> binary arithmetic and eliminating the necessity to palloc() buffers for every
> temporary result.
I don't have any objection in principle to an additional datatype "small
numeric", or some such name, with a different representation. I do
object to emasculating the type we have.
A more significant point is that you have presented no evidence to back
up your claim that this would be materially faster than the existing
type. I doubt that the extra pallocs are all that expensive. (I think
it'd be far more helpful to reimplement numeric using base-10000
representation --- four decimal digits per int16 --- and then eliminate
the distinction between storage format and computation format. See past
discussions in the pghackers archives.)
regards, tom lane
