Re: [PERFORM] pgbench to the MAXINT
От | Greg Smith |
---|---|
Тема | Re: [PERFORM] pgbench to the MAXINT |
Дата | |
Msg-id | 4D35DF33.6060901@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] pgbench to the MAXINT (Euler Taveira de Oliveira <euler@timbira.com>) |
Ответы |
Re: [PERFORM] pgbench to the MAXINT
Re: [PERFORM] pgbench to the MAXINT |
Список | 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 по дате отправления: