Re: NUMERIC type efficiency problem

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

Weren't you just complaining about excess palloc's ;-) ? Seriously,
I have no idea about the costs/benefits of aligning data on disk.
That decision was made way back in the Berkeley days, and hasn't been
questioned since then AFAIK. Feel free to experiment if you are
interested.

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

Given that the "more efficient representation" would only be internal to
calculation subroutines, it seems easier to exploit preallocation at
runtime. This is already done in a number of places in Postgres.
It'd look something like

{
digit *tmp;
digit tmpbuf[MAX_FIXED_DIGITS];

if (digits_needed > MAX_FIXED_DIGITS)
tmp = palloc(...);
else
tmp = tmpbuf;

// use tmp here

if (tmp != tmpbuf)
pfree(tmp);
}

Ugly, but most of the ugliness could be hidden inside a couple of
macros.

Again, though, I wouldn't bother with this until I had some profiles
proving that the palloc overhead is worth worrying about.

regards, tom lane