Re: [PERFORM] pgbench to the MAXINT - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PERFORM] pgbench to the MAXINT
Date
Msg-id 4D35DF33.6060901@2ndquadrant.com
Whole thread Raw
In response to Re: [PERFORM] pgbench to the MAXINT  (Euler Taveira de Oliveira <euler@timbira.com>)
Responses Re: [PERFORM] pgbench to the MAXINT  (Robert Haas <robertmhaas@gmail.com>)
Re: [PERFORM] pgbench to the MAXINT  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
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    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: pg_basebackup for streaming base backups
Next
From: Tom Lane
Date:
Subject: Performance bug in DO blocks