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: http://www.postgresql.org/mailpref/pgsql-hackers
