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
