Re: numeric/decimal docs bug? - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: numeric/decimal docs bug?
Date
Msg-id 3CB6DF24.B50B407@fourpalms.org
Whole thread Raw
In response to Re: numeric/decimal docs bug?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: numeric/decimal docs bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
...
> Also, the numeric regression tests takes much longer than the other
> tests.  I don't see why a test of that length is required, compared to
> the other tests.  Probably time to pair it back a little.

The numeric types are inherently slow. You might look at what effect you
can achieve by restructuring that regression test to more closely
resemble the other tests. In particular, it defines several source
tables, each one of which containing similar initial values. And it
defines a results table, into which intermediate results are placed,
which are then immediately queried for display and comparison to obtain
a test result. If handling the values is slow, we could certainly remove
these intermediate steps and still get most of the test coverage.

On another related topic:

I've been wanting to ask: we have in a few cases moved aggregate
calculations from small, fast data types to using numeric as the
accumulator. It would be nice imho to allow, say, an int8 accumulator
for an int4 data type, rather than requiring numeric.

But not all platforms (I assume) have an int8 data type. So we would
need to be able to fall back to numeric for those platforms which need
to use it. What would it take to make some of the catalogs configurable
or sensitive to configuration results?
                    - Thomas


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: numeric/decimal docs bug?
Next
From: Tom Lane
Date:
Subject: Re: 7.3 schedule