Re: NUMERIC type efficiency problem

Mark Butler <butlerm(at)middle(dot)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