From: Greg Smith <greg@2ndquadrant.com>
To: Euler Taveira de Oliveira <euler@timbira.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] pgbench to the MAXINT
Date: Tue, 18 Jan 2011 13:42:59 -0500
Message-ID: <4D35DF33.6060901@2ndquadrant.com> (raw)
In-Reply-To: <4D2CCCD9.802@timbira.com>
References: <4D27C4E5.5000609@2ndquadrant.com>
<4D2A965A.3000603@timbira.com>
<4D2AC273.3010709@2ndquadrant.com>
<4D2CCCD9.802@timbira.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: greg@2ndquadrant.com, euler@timbira.com, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] pgbench to the MAXINT
In-Reply-To: <4D35DF33.6060901@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox