Euler Taveira de Oliveira wrote:
(i) If we want to support and scale factor greater than 21474 we have
to convert some columns to bigint; it will change the test. From the
portability point it is a pity but as we have never supported it I'm
not too worried about it. Why? Because it will use bigint columns only
if the scale factor is greater than 21474. Is it a problem? I don't
think so because generally people compare tests with the same scale
factor.
(ii) From the performance perspective, we need to test if the
modifications don't impact performance. I don't create another code
path for 64-bit modifications (it is too ugly) and I'm afraid some
modifications affect the 32-bit performance. I'm in a position to test
it though because I don't have a big machine ATM. Greg, could you lead
these tests?
(iii) I decided to copy scanint8() (called strtoint64 there) from
backend (Robert suggestion [1]) because Tom pointed out that strtoll()
has portability issues. I replaced atoi() with strtoint64() but didn't
do any performance tests.
(i): Completely agreed.
(ii): There is no such thing as a "big machine" that is 32 bits now;
anything that's 32 is a tiny system here in 2011. What I can do is
check for degredation on the only 32-bit system I have left here, my
laptop. I'll pick a sensitive test case and take a look.
(iii) This is an important thing to test, particularly given it has the
potential to impact 64-bit results too.
Thanks for picking this up again and finishing the thing off. I'll add
this into my queue of performance tests to run and we can see if this is
worth applying. Probably take a little longer than the usual CF review
time. But as this doesn't interfere with other code people are working
on and is sort of a bug fix, I don't think it will be a problem if it
takes a little longer to get this done.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
