Re: numeric_big test - Mailing list pgsql-hackers

From Tom Lane
Subject Re: numeric_big test
Date
Msg-id 22205.1223036895@sss.pgh.pa.us
Whole thread Raw
In response to numeric_big test  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> The numeric_big regression test was added many years ago for the NUMERIC 
>   implementation but was not put in the default test set because it was 
> too slow.  Now my tests show, it is really not slower than some of the 
> other slow tests (e.g., stats, tablespace), so perhaps time has caught 
> up with us and we can now test it by default.

The other side of the coin is what would it possibly tell us that is
worth any extra cycles at all?  We do run it (at least I do) when
touching the numeric datatype.  Given the lack of machine dependence in
that code, it seems unlikely that running numeric_big at other times
would turn up anything.  I can't see that it's worth slowing down
everyone's regression tests for.

(As somebody who frequently runs the regression tests dozens of times a
day, I grudge any unnecessarily expensive testing...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marko Kreen"
Date:
Subject: Re: pgsql: Add relation fork support to pg_relation_size() function.
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Add relation fork support to pg_relation_size() function.