Re: [PERFORM] pgbench to the MAXINT

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] pgbench to the MAXINT
Date: 2011-01-18 18:42:59
Message-ID: 4D35DF33.6060901@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-18 18:46:12 Performance bug in DO blocks
Previous Message Simon Riggs 2011-01-18 18:36:13 Re: pg_basebackup for streaming base backups

Browse pgsql-performance by date

  From Date Subject
Next Message masterchief 2011-01-18 18:56:59 Re: hashed subplan 5000x slower than two sequential operations
Previous Message Mladen Gogala 2011-01-18 14:26:21 Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2