Re: NUMERIC type efficiency problem

Tom Lane wrote:

> Yawn ... given row overhead, alignment padding, etc, this is not nearly
> as big a deal as you make it ...

For a table with ten decimal columns with an average of 5 significant digits
apiece, each row could be reduced from ~170 bytes to about ~90 bytes, which
could be rather significant, I would think. (In Oracle such a row takes ~55
bytes.)

By the way, is alignment padding really a good use of disk space? Surely
storage efficiency trumps minor CPU overhead in any I/O bound database. Or
are there other considerations? (like processor portability perhaps?)

> 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.

Surely we can't get rid of it, but it might be a good idea to make NUMERIC(p)
map to multiple representations, given that it is a ANSI standard data-type.

I suggest using a system like the FLOAT(p) -> float4 / float8 mapping.
Columns declared with precisions higher than 16 or so could map to the current
unrestricted representation, and columns with more typical precisions could
map to a more efficient fixed length representation.

> 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.)

That sounds like it would help a lot. I certainly don't have any hard
evidence yet. Thanks for the pointer.

- Mark Butler