Update README.md

Clarify explanations

Author: simonat2ndQuadrant

contrib/fixeddecimal/README.md

@@ -11,14 +11,18 @@ features of PostgreSQL's builtin NUMERIC type, but with vastly increased
 performance. Fixeddecimal is targeted to cases where performance and disk space
 are a critical.
 
+Just use FIXEDDECIMAL(n, 2) rather than NUMERIC(n, 2) for n=3..17
+
 Often there are data storage requirements where the built in REAL and
 DOUBLE PRECISION types cannot be used due to the non-exact representation of
 numbers using these types, e.g. where monetary values need to be stored. In many
 of these cases NUMERIC is an almost perfect type, although with NUMERIC
 performance is no match for the performance of REAL or DOUBLE PRECISION, as
-these use CPU native processor types. FixedDecimal aims to offer performance
-advantages over NUMERIC without the imprecise representations that are
-apparent in REAL and DOUBLE PRECISION, but it comes with some caveats...
+these use CPU native processor types. 
+
+FixedDecimal delivers performance advantages over NUMERIC with full precision for
+addition and subtraction. Just as occurs with REAL and DOUBLE PRECISION, there
+are some caveats for multiplication and division.
 
 Behavioural differences between FIXEDDECIMAL and NUMERIC
 --------------------------------------------------------
@@ -50,8 +54,9 @@ implementations as in the case with NUMERIC.
 FIXEDDECIMAL has a fixed scale value, which by default is 2. Internally numbers
 are stores as the actual value multiplied by 100. e.g. 50 would be stored as
 5000, and 1.23 would be stored as 123. This internal representation allows very
-fast addition and subtraction between two fixeddecimal types. Multiplication
-between two fixeddecimal types is slightly more complex.  If we wanted to
+fast and accurate addition and subtraction between two fixeddecimal types.
+
+Multiplication between two fixeddecimal types is slightly more complex.  If we
 perform 2.00 * 3.00 in fixeddecimal, internally these numbers would be 200 and
 300 respectively, so internally 200 * 300 becomes 60000, which must be divided
 by 100 in order to obtain the correct internal result of 600, which of course
@@ -113,7 +118,7 @@ test=# select '1.239'::fixeddecimal;
 
 It is especially important to remember that this truncation also occurs during
 arithmetic. Notice in the following example the result is 1120 rather than
-1129:
+1129, since 1.129 is immediately rounded to 1.12 on input.
 
 ```
 test=# select '1000'::fixeddecimal * '1.129'::fixeddecimal;