On Mon, Jun 19, 2017 at 12:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> It would be interesting to get some handle on the performance differences
> between decNumber and our existing NUMERIC implementation.  I'm a little
> skeptical that they'd be so enormous as to make this an interesting
> project, but I could be wrong.

I've never been very happy with the performance of numeric, so I guess
I'm a bit more optimistic about the chances of doing better.  Aside
from any computational optimizations, the fact that the datatype could
be pass-by-value rather than a varlena might speed things up quite a
bit in some cases.

On the other hand, the 8-byte version has a decent chance of being
larger on disk than the numeric representation - e.g. $123,456.78 is
only 7 bytes as a short varlena, and won't induce padding out to the
next 8-byte boundary.  And it looks to me like the 4-byte version
can't represent that quantity at all.  That combination of facts seems
like a big problem to me.   A decimal representation that can't handle
more than 7 digits is going to unsuitable for many applications, and
being bigger than our existing numeric on disk for many
commonly-represented values would be awful.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to