Re: Reducing the overhead of NUMERIC data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the overhead of NUMERIC data
Date
Msg-id 14853.1130976764@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing the overhead of NUMERIC data  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Reducing the overhead of NUMERIC data  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Could someone please quantify how much bang we might get for what seems
> like quite a lot of bucks?
> I appreciate the need for speed, but the saving here strikes me as
> marginal at best, unless my instincts are all wrong (quite possible)

Two bytes per numeric value is not a lot, agreed.

If we were willing to invent the "varlena2" datum format then we could
save four bytes per numeric, plus reduce numeric's alignment requirement
from int to short which would probably save another byte per value on
average.  I'm not sure that that's worth doing if numeric and inet are
the only beneficiaries, but it might be.

From a speed perspective the only thing favoring UNKNOWNNUMERIC is the
possibility for saving some conversion operations when the grammar's
initial guess about datatype is wrong.  That's probably pretty marginal
though.  I was thinking of it more as a vehicle for helping us clean up
the type-assignment behavior some more.  The example I have in my notes
is that "float4col = 1.8" is certain to fail since 1.8 will be taken as
float8, not float4, and then you have precision mismatch problems.
You can make it work by quoting: "float4col = '1.8'" but that's surely
pretty ugly.  If the constant were initially UNKNOWNNUMERIC then it
would end up as float4 without that hack.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Assert failure found in 8.1RC1
Next
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data