Re: [PERFORM] New to PostgreSQL, performance considerations

Sorry for the delay in responding. I had familial obligations. As a matter of fact, I am spending a decent amount of time on this. I don't usually pore through documentation for compilers and OS's to the degree I've been since this thread started. Nor do I usually try and get access to the

Re: [PERFORM] New to PostgreSQL, performance considerations

On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote: The most important "gain" IMO is Knowledge, and I'd say there is still more to learn and/or verify IMHO. YMMV. Well, I think there are other areas where I can spend my time where potential gains are more likely. YMMV (although, I note, you d

Re: [PERFORM] New to PostgreSQL, performance considerations

On Sat, Dec 16, 2006 at 10:53:21AM -0500, Ron wrote: > AFAICT, no one has stated there would be a "blow-your-socks-off > dramatic performance improvement" for pg due to compilation > options. Just that there might be some, and there might be some that > are arch specific. FWIW, the original cl

Re: [PERFORM] New to PostgreSQL, performance considerations

At 07:06 PM 12/15/2006, Michael Stone wrote: On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote: ATM, the most we can say is that in a number of systems with modest physical IO subsystems So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't the bottleneck on that one. Results

Re: [PERFORM] New to PostgreSQL, performance considerations

Alexander Staubo wrote: On Dec 15, 2006, at 17:53 , Ron wrote: At 09:50 AM 12/15/2006, Greg Smith wrote: On Fri, 15 Dec 2006, Merlin Moncure wrote: The slower is probably due to the unroll loops switch which can actually hurt code due to the larger footprint (less cache coherency). The

Re: [PERFORM] New to PostgreSQL, performance considerations

On Fri, Dec 15, 2006 at 12:24:46PM -0500, Ron wrote: ATM, the most we can say is that in a number of systems with modest physical IO subsystems So I reran it on a 3.2GHz xeon with 6G RAM off a ramdisk; I/O ain't the bottleneck on that one. Results didn't show didn't show any signficant gain

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 15, 2006, at 17:53 , Ron wrote: At 09:50 AM 12/15/2006, Greg Smith wrote: On Fri, 15 Dec 2006, Merlin Moncure wrote: The slower is probably due to the unroll loops switch which can actually hurt code due to the larger footprint (less cache coherency). The cache issues are so impor

Re: [PERFORM] New to PostgreSQL, performance considerations

At 10:55 AM 12/15/2006, Merlin Moncure wrote: On 12/15/06, Ron <[EMAIL PROTECTED]> wrote: There are many instances of x86 compatible code that get 30-40% speedups just because they get access to 16 rather than 8 GPRs when recompiled for x84-64. ...We benchmarked PostgreSQL internally here and

Re: [PERFORM] New to PostgreSQL, performance considerations

At 09:50 AM 12/15/2006, Greg Smith wrote: On Fri, 15 Dec 2006, Merlin Moncure wrote: The slower is probably due to the unroll loops switch which can actually hurt code due to the larger footprint (less cache coherency). The cache issues are so important with current processors that I'd sugge

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/15/06, Ron <[EMAIL PROTECTED]> wrote: At 09:23 AM 12/15/2006, Merlin Moncure wrote: >On 12/15/06, Ron <[EMAIL PROTECTED]> wrote: >> >>It seems unusual that code generation options which give access to >>more registers would ever result in slower code... > >The slower is probably due to the

Re: [PERFORM] New to PostgreSQL, performance considerations

At 09:23 AM 12/15/2006, Merlin Moncure wrote: On 12/15/06, Ron <[EMAIL PROTECTED]> wrote: It seems unusual that code generation options which give access to more registers would ever result in slower code... The slower is probably due to the unroll loops switch which can actually hurt code d

Re: [PERFORM] New to PostgreSQL, performance considerations

On Fri, 15 Dec 2006, Merlin Moncure wrote: The slower is probably due to the unroll loops switch which can actually hurt code due to the larger footprint (less cache coherency). The cache issues are so important with current processors that I'd suggest throwing -Os (optimize for size) into th

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/15/06, Ron <[EMAIL PROTECTED]> wrote: I'm looking more closely into exactly what the various gcc -O optimizations do on Kx's as well. 64b vs 32b gets x86 compatible code access to ~ 2x as many registers; and MMX or SSE instructions get you access to not only more registers, but wider ones a

Re: [PERFORM] New to PostgreSQL, performance considerations

At 04:54 AM 12/15/2006, Alexander Staubo wrote: On Dec 15, 2006, at 04:09 , Ron wrote: At 07:27 PM 12/14/2006, Alexander Staubo wrote: Sorry, I neglected to include the pertinent graph: http://purefiction.net/paste/pgbench2.pdf In fact, your graph suggests that using arch specific options

Re: [PERFORM] New to PostgreSQL, performance considerations

On Fri, Dec 15, 2006 at 10:53:25AM +0100, Alexander Staubo wrote: > The difference is very slight. I'm going to run without -funroll- > loops and -pipe (which are not arch-related) to get better data. -pipe does not matter for the generated code; it only affects compiler speed. (It simply means t

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 15, 2006, at 04:09 , Ron wrote: At 07:27 PM 12/14/2006, Alexander Staubo wrote: Sorry, I neglected to include the pertinent graph: http://purefiction.net/paste/pgbench2.pdf In fact, your graph suggests that using arch specific options in addition to -O3 actually =hurts= performance

Re: [PERFORM] New to PostgreSQL, performance considerations

On Thu, 14 Dec 2006, Alexander Staubo wrote: Interestingly enough I see that PostgreSQL seems to be writing around 1MB/s during the pgbench run, even though I'm running pgbench in the -S mode. I haven't had the chance to look at the source yet; is it really only doing selects? I've noticed t

Re: [PERFORM] New to PostgreSQL, performance considerations

At 07:27 PM 12/14/2006, Alexander Staubo wrote: Sorry, I neglected to include the pertinent graph: http://purefiction.net/paste/pgbench2.pdf In fact, your graph suggests that using arch specific options in addition to -O3 actually =hurts= performance. ...that seems unexpected... Ron Peacet

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 15, 2006, at 01:16 , Ron wrote: At 05:39 PM 12/14/2006, Alexander Staubo wrote: On Dec 14, 2006, at 20:28 , Ron wrote: Can you do runs with just CFLAGS="-O3" and just CFLAGS="-msse2 - mfpmath=sse -funroll-loops -m64 - march=opteron -pipe" as well ? All right. From my perspective, th

Re: [PERFORM] New to PostgreSQL, performance considerations

At 05:39 PM 12/14/2006, Alexander Staubo wrote: On Dec 14, 2006, at 20:28 , Ron wrote: Can you do runs with just CFLAGS="-O3" and just CFLAGS="-msse2 - mfpmath=sse -funroll-loops -m64 - march=opteron -pipe" as well ? All right. From my perspective, the effect of -O3 is significant, whereas a

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 14, 2006, at 20:28 , Ron wrote: Can you do runs with just CFLAGS="-O3" and just CFLAGS="-msse2 - mfpmath=sse -funroll-loops -m64 - march=opteron -pipe" as well ? All right. From my perspective, the effect of -O3 is significant, whereas architecture-related optimizations have no statis

Re: [PERFORM] New to PostgreSQL, performance considerations

Alexander, Good stuff. Can you do runs with just CFLAGS="-O3" and just CFLAGS="-msse2 -mfpmath=sse -funroll-loops -m64 - march=opteron -pipe" as well ? As it is, you've given a good lower and upper bound on your performance obtainable using compiler options, but you've given no data to sho

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 14, 2006, at 16:00 , Greg Smith wrote: On Wed, 13 Dec 2006, Ron wrote: The slowest results, Michael's, are on the system with what appears to be the slowest CPU of the bunch; and the ranking of the rest of the results seem to similarly depend on relative CPU performance. This is n

Re: [PERFORM] New to PostgreSQL, performance considerations

Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: On Wed, 2006-12-13 at 18:36 -0800, Josh Berkus wrote: Mostly, though, pgbench just gives the I/O system a workout. It's not a really good general workload. It also will not utilize all cpus on a many cpu machine. We recently foun

Re: [PERFORM] New to PostgreSQL, performance considerations

At 10:00 AM 12/14/2006, Greg Smith wrote: On Wed, 13 Dec 2006, Ron wrote: The slowest results, Michael's, are on the system with what appears to be the slowest CPU of the bunch; and the ranking of the rest of the results seem to similarly depend on relative CPU performance. This is not what

Re: [PERFORM] New to PostgreSQL, performance considerations

On Wed, Dec 13, 2006 at 01:03:04PM -0500, Ron wrote: What I find interesting is that so far Guido's C2D Mac laptop has gotten the highest values by far in this set of experiments, and no one else is even close. The slowest results, Michael's, are on the system with what appears to be the slowes

Re: [PERFORM] New to PostgreSQL, performance considerations

On Thu, 14 Dec 2006, Tom Lane wrote: The pgbench app itself becomes the bottleneck at high transaction rates. Awhile back I rewrote it to improve its ability to issue commands concurrently, but then desisted from submitting the changes --- if we change the app like that, future numbers would b

Re: [PERFORM] New to PostgreSQL, performance considerations

On Wed, 13 Dec 2006, Ron wrote: The slowest results, Michael's, are on the system with what appears to be the slowest CPU of the bunch; and the ranking of the rest of the results seem to similarly depend on relative CPU performance. This is not what one would naively expect when benching a IO

Re: [PERFORM] New to PostgreSQL, performance considerations

osh Berkus; pgsql-performance@postgresql.org; Bruce Momjian; Alvaro Herrera; Alexander Staubo; Michael Stone Subject: Re: [PERFORM] New to PostgreSQL, performance considerations On Dec 14, 2006, at 14:44 , Tom Lane wrote: > The pgbench app itself becomes the bottleneck at high transa

Re: [PERFORM] New to PostgreSQL, performance considerations

Benchmarks, like any other SW, need modernizing and updating from time to time. Given the multi-core CPU approach to higher performance as the current fad in CPU architecture, we need a benchmark that is appropriate. If SPEC feels it is appropriate to rev their benchmark suite regularly, we p

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 14, 2006, at 14:44 , Tom Lane wrote: The pgbench app itself becomes the bottleneck at high transaction rates. Awhile back I rewrote it to improve its ability to issue commands concurrently, but then desisted from submitting the changes --- if we change the app like that, future numbers

Re: [PERFORM] New to PostgreSQL, performance considerations

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > On Wed, 2006-12-13 at 18:36 -0800, Josh Berkus wrote: >> Mostly, though, pgbench just gives the I/O system a workout. It's not a >> really good general workload. > It also will not utilize all cpus on a many cpu machine. We recently > found that th

Re: [PERFORM] New to PostgreSQL, performance considerations

On Wed, 2006-12-13 at 18:36 -0800, Josh Berkus wrote: > Bruce, > > > pgbench is designed to be a general benchmark, meanining it exercises > > all parts of the system. I am thinking just reexecuting a single SELECT > > over and over again would be a better test of the CPU optimizations. > > Most

Re: [PERFORM] New to PostgreSQL, performance considerations

Bruce, > pgbench is designed to be a general benchmark, meanining it exercises > all parts of the system. I am thinking just reexecuting a single SELECT > over and over again would be a better test of the CPU optimizations. Mostly, though, pgbench just gives the I/O system a workout. It's not a

Re: [PERFORM] New to PostgreSQL, performance considerations

[offtopic]; hmm quite a long thread below is stats of posting Total Messages:87Total Participants: 27 - 19 Daniel van Ham Colchete 12 Michael Stone 9 Ron 5 Steinar H. Gunderson 5 Alexander Staubo 4 Tom Lane 4 Greg

Re: [PERFORM] New to PostgreSQL, performance considerations

Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > While skimming over the pgbench source it has looked to me like it's > > necessary to pass the -s switch (scale factor) to both the > > initialization (-i) and the subsequent (non -i) runs. > > No, it's not supposed to be, and I've n

Re: [PERFORM] New to PostgreSQL, performance considerations

On 13.12.2006, at 19:03, Ron wrote: What I find interesting is that so far Guido's C2D Mac laptop has gotten the highest values by far in this set of experiments, and no one else is even close. This might be the case because I have tested with fsync=off as my internal harddrive would be a

Re: [PERFORM] New to PostgreSQL, performance considerations

At 01:49 PM 12/13/2006, Bucky Jordan wrote: I've only seen pg_bench numbers > 2,000 tps on either really large hardware (none of the above mentioned comes close) or the results are in memory due to a small database size (aka measuring update contention). Which makes a laptop achieving such num

Re: [PERFORM] New to PostgreSQL, performance considerations

> What I find interesting is that so far Guido's C2D Mac laptop has > gotten the highest values by far in this set of experiments, and no > one else is even close. > The slowest results, Michael's, are on the system with what appears > to be the slowest CPU of the bunch; and the ranking of the rest

Re: [PERFORM] New to PostgreSQL, performance considerations

At 11:11 AM 12/13/2006, Cosimo Streppone wrote: Interesting, eh? Cosimo What I find interesting is that so far Guido's C2D Mac laptop has gotten the highest values by far in this set of experiments, and no one else is even close. The slowest results, Michael's, are on the system with what a

Re: [PERFORM] New to PostgreSQL, performance considerations

Michael Stone wrote: On Tue, Dec 12, 2006 at 01:42:06PM +0100, Cosimo Streppone wrote: "-O0" ~ 957 tps "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps

Re: [PERFORM] New to PostgreSQL, performance considerations

Hi, Did someone try '-mfpmath=sse -msse3'? Would be interesting to know if -mfpmath=sse boost the performance. I guess, the difference in the generated code isn't that much between i686 and prescott. The bigger step is i386 to i686. '-mfpmath=sse -msse3' will also use the SSE unit, which the cla

Re: [PERFORM] New to PostgreSQL, performance considerations

[EMAIL PROTECTED] (Alexander Staubo) wrote: > On Dec 12, 2006, at 13:32 , Michael Stone wrote: > >> On Tue, Dec 12, 2006 at 12:29:29PM +0100, Alexander Staubo wrote: >>> I suspect the hardware's real maximum performance of the system is >>> ~150 tps, but that the LSI's write cache is buffering the

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, 12 Dec 2006, Daniel van Ham Colchete wrote: I'm making some other tests here at another hardware (also Gentoo). I found out that PostgreSQL stops for a while if I change the -t parameter on bgbench from 600 to 1000 and I have ~150 tps instead of ~950tps. Sure sounds like a checkpoint t

Re: [PERFORM] New to PostgreSQL, performance considerations

> I just made another test with a second Gentoo machine: > > Pentium 4 3.0Ghz Prescott > GCC 4.1.1 > Glibc 2.4 > PostgreSQL 8.1.5 > Kernel 2.6.17 > > Same postgresql.conf as yesterday's. > > First test > == > GLIBC: -O2 -march=i686 > PostgreSQL: -O2 -march=i686 > Results: 974.63873

Re: [PERFORM] New to PostgreSQL, performance considerations

At 01:35 PM 12/12/2006, Daniel van Ham Colchete wrote: I just made another test with a second Gentoo machine: The results showed no significant change. The conclusion of today's test would be that there are no improvement at PostgreSQL when using -march=prescott. I only see 3 diferences

Re: [PERFORM] New to PostgreSQL, performance considerations

I just made another test with a second Gentoo machine: Pentium 4 3.0Ghz Prescott GCC 4.1.1 Glibc 2.4 PostgreSQL 8.1.5 Kernel 2.6.17 Same postgresql.conf as yesterday's. First test == GLIBC: -O2 -march=i686 PostgreSQL: -O2 -march=i686 Results: 974.638731 975.602142 975.882051 969.1425

Re: [PERFORM] New to PostgreSQL, performance considerations

At 10:47 AM 12/12/2006, Tom Lane wrote: It's notoriously hard to get repeatable numbers out of pgbench :-( That's not a good characteristic in bench marking SW... Does the ODSL stuff have an easier time getting reproducible results? A couple of tips: * don't put any faith in short

Re: [PERFORM] New to PostgreSQL, performance considerations

"Daniel van Ham Colchete" <[EMAIL PROTECTED]> writes: > I'm making some other tests here at another hardware (also Gentoo). I > found out that PostgreSQL stops for a while if I change the -t > parameter on bgbench from 600 to 1000 and I have ~150 tps instead of > ~950tps. > I don't know why Postgr

Re: [PERFORM] New to PostgreSQL, performance considerations

Alvaro Herrera <[EMAIL PROTECTED]> writes: > While skimming over the pgbench source it has looked to me like it's > necessary to pass the -s switch (scale factor) to both the > initialization (-i) and the subsequent (non -i) runs. No, it's not supposed to be, and I've never found it needed in prac

Re: [PERFORM] New to PostgreSQL, performance considerations

Mike, I'm making some other tests here at another hardware (also Gentoo). I found out that PostgreSQL stops for a while if I change the -t parameter on bgbench from 600 to 1000 and I have ~150 tps instead of ~950tps. I don't know why PostgreSQL stoped, but it was longer than 5 seconds and my dis

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, 12 Dec 2006, Alvaro Herrera wrote: While skimming over the pgbench source it has looked to me like it's necessary to pass the -s switch (scale factor) to both the initialization (-i) and the subsequent (non -i) runs. For non-custom runs, it's computed based on the number of branches.

Re: [PERFORM] New to PostgreSQL, performance considerations

Tom Lane wrote: > Alexander Staubo <[EMAIL PROTECTED]> writes: > > No, fsync=on. The tps values are similarly unstable with fsync=off, > > though -- I'm seeing bursts of high tps values followed by low-tps > > valleys, a kind of staccato flow indicative of a write caching being > > filled up

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, 12 Dec 2006, Tom Lane wrote: Um, you entirely missed the point: the hardware speedups you mention are quite independent of any compiler options. The numbers we are looking at are the relative speeds of two different compiles on the same hardware, not whether hardware A is faster than ha

Re: [PERFORM] New to PostgreSQL, performance considerations

Alexander Staubo wrote: No, fsync=on. The tps values are similarly unstable with fsync=off, though -- I'm seeing bursts of high tps values followed by low-tps valleys, a kind of staccato flow indicative of a write caching being filled up and flushed. Databases with checkpointing typically

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/12/06, Florian Weimer <[EMAIL PROTECTED]> wrote: * Cosimo Streppone: > "-O0" ~ 957 tps > "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps > "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps > "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps > "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps -m

Re: [PERFORM] New to PostgreSQL, performance considerations

Alexander Staubo <[EMAIL PROTECTED]> writes: > No, fsync=on. The tps values are similarly unstable with fsync=off, > though -- I'm seeing bursts of high tps values followed by low-tps > valleys, a kind of staccato flow indicative of a write caching being > filled up and flushed. It's notorio

Re: [PERFORM] New to PostgreSQL, performance considerations

In response to Ron <[EMAIL PROTECTED]>: > > 3= Daniel van Ham Colchete is running Gentoo. That means every SW > component on his box has been compiled to be optimized for the HW it > is running on. > There may be a combination of effects going on for him that others > not running a system opti

Re: [PERFORM] New to PostgreSQL, performance considerations

* Cosimo Streppone: > "-O0" ~ 957 tps > "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps > "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps > "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps > "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps -mcpu and -mtune are synonymous. You really should -march

Re: [PERFORM] New to PostgreSQL, performance considerations

1= In all these results I'm seeing, no one has yet reported what their physical IO subsystem is... ...when we are benching a DB. 2= So far we've got ~ a factor of 4 performance difference between Michael Stone's 1S 1C Netburst era 2.5GHz P4 PC and Guido Neitzer's 1S 2C MacBook Pro 2.33GHz C2D

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 12, 2006, at 13:32 , Michael Stone wrote: On Tue, Dec 12, 2006 at 12:29:29PM +0100, Alexander Staubo wrote: I suspect the hardware's real maximum performance of the system is ~150 tps, but that the LSI's write cache is buffering the writes. I would love to validate this hypothesis,

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, 2006-12-11 at 20:22 -0200, Daniel van Ham Colchete wrote: > > I'm thinking about writing a script to make all the tests (more than 3 > times each), get the data and plot some graphs. > > I don't have the time right now to do it, maybe next week I'll have. Check out the OSDL test suite st

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 07:48:06AM -0500, Michael Stone wrote: I'd be curious to see -O2 with and without the arch-specific flags, since that's mostly what the discussion is about. That came across more harshly than I intended; I apologize for that. It's certainly a useful data point to compa

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 01:42:06PM +0100, Cosimo Streppone wrote: "-O0" ~ 957 tps "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps I'm curious now to get

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 01:42:06PM +0100, Cosimo Streppone wrote: > "-O0" ~ 957 tps > "-O1 -mcpu=pentium4 -mtune=pentium4" ~ 1186 tps > "-O2 -mcpu=pentium4 -mtune=pentium4" ~ 1229 tps > "-O3 -mcpu=pentium4 -mtune=pentium4" ~ 1257 tps > "-O6 -mcpu=pentium4 -mtune=pentium4" ~ 1254 tps For the record

Re: [PERFORM] New to PostgreSQL, performance considerations

Luke Lonergan wrote: Can you try this with just "-O3" versus "-O2"? Thanks to Daniel for doing these tests. I happen to have done the same tests about 3/4 years ago, and concluded that gcc flags did *not* influence performance. Moved by curiosity, I revamped those tests now on a test machine

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 12:29:29PM +0100, Alexander Staubo wrote: I suspect the hardware's real maximum performance of the system is ~150 tps, but that the LSI's write cache is buffering the writes. I would love to validate this hypothesis, but I'm not sure how. With fsync off? The write cac

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 07:10:34AM -0200, Daniel van Ham Colchete wrote: are you using "-mtune/-mcpu" or "-march" with GCC? I used exactly the options you said you used. Witch GCC version? Are you working with a 32bits OS or 64bits? 3.3.5; 32 Mike Stone ---(end of

Re: [PERFORM] New to PostgreSQL, performance considerations

On Tue, Dec 12, 2006 at 01:35:04AM -0500, Greg Smith wrote: These changes could easily explain the magnitude of difference in results you're seeing, expecially when combined with a 20% greater raw CPU clock. I'm not interested in comparing the numbers between the systems (which is obviously po

Re: [PERFORM] New to PostgreSQL, performance considerations

On Dec 11, 2006, at 23:22 , Daniel van Ham Colchete wrote: I ran this test at a Gentoo test machine I have here. It's a Pentium 4 3.0GHz (I don't know witch P4) Try cat /proc/cpuinfo. TESTS RESULTS == On a dual-core Opteron 280 with 4G RAM with an LSI PCI-X Fusion-MPT SAS con

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12.12.2006, at 02:37, Michael Stone wrote: Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, 1.5G RAM) and my test results are more like this: I'm on totally different hardware / software (MacBook Pro 2.33GHz C2D) and I can't reproduce the tests. I have playe

Re: [PERFORM] New to PostgreSQL, performance considerations

Mike, are you using "-mtune/-mcpu" or "-march" with GCC? Witch GCC version? Are you working with a 32bits OS or 64bits? Daniel On 12/11/06, Michael Stone <[EMAIL PROTECTED]> wrote: Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, 1.5G RAM) and my test results are m

Re: [PERFORM] New to PostgreSQL, performance considerations

Greg Smith <[EMAIL PROTECTED]> writes: > On Mon, 11 Dec 2006, Michael Stone wrote: >> Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, >> 1.5G RAM)... > There are two likely candidates for why Daniel's P4 3.0GHz significantly > outperforms your 2.5GHz system. Um, you

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, 11 Dec 2006, Michael Stone wrote: Can anyone else reproduce these results? I'm on similar hardware (2.5GHz P4, 1.5G RAM)... There are two likely candidates for why Daniel's P4 3.0GHz significantly outperforms your 2.5GHz system. 1) Most 2.5GHZ P4 processors use a 533MHz front-side b

Re: [PERFORM] New to PostgreSQL, performance considerations

After a long battle with technology, [EMAIL PROTECTED] (Michael Stone), an earthling, wrote: > [1] I will say that I have never seen a realistic benchmark of > general code where the compiler flags made a statistically > significant difference in the runtime. When we were initially trying out Pos

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 08:22:42PM -0200, Daniel van Ham Colchete wrote: TEST 01: CFLAGS="-O2 -march=i686" fsync=false tps = 734.948620 (including connections establishing) tps = 736.866642 (excluding connections establishing) [snip] TEST 03: CFLAGS="-O2 -march=pentium4" fsync=false tps = 846

Re: [PERFORM] New to PostgreSQL, performance considerations

Daniel, Good stuff. Can you try this with just "-O3" versus "-O2"? - Luke On 12/11/06 2:22 PM, "Daniel van Ham Colchete" <[EMAIL PROTECTED]> wrote: > Hi yall, > > I made some preliminary tests. > > Before the results, I would like to make some acknowledgments: > 1 - I didn't show any prove

Re: [PERFORM] New to PostgreSQL, performance considerations

Hi yall, I made some preliminary tests. Before the results, I would like to make some acknowledgments: 1 - I didn't show any prove to any of the things I said until now. 2 - It really is a waste of everyone's time to say one thing when I can't prove it. But all I said, is the knowledge I have b

Re: [PERFORM] New to PostgreSQL, performance considerations

Daniel van Ham Colchete wrote: On 12/11/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: > What PostgreSQL benchmark software should I use??? Look up the list archives; search for "TPC". > I'll test PostgreSQL 8.1 on a

Re: [PERFORM] New to PostgreSQL, performance considerations

Ron wrote: We are not going to get valuable contributions nor help people become more valuable to the community by "flaming them into submission". Let's support getting definitive evidence. No matter who brings it to the table ;-) Thanks, Ron, for a voice of respect and reason. Since I fir

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Chris Browne <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] ("Daniel van Ham Colchete") writes: > You are right Christopher. > > Okay. Let's solve this matter. > > What PostgreSQL benchmark software should I use??? pgbench is one option. There's a TPC-W at pgFoundry (

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 02:51:09PM -0500, Ron wrote: Let's support getting definitive evidence. Since nobody opposed the concept of contrary evidence, I don't suppose you're fighting an uphill battle on that particular point. It's fine to get preachy about supporting intellectual curiosity,

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: > What PostgreSQL benchmark software should I use??? Look up the list archives; search for "TPC". > I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo.

Re: [PERFORM] New to PostgreSQL, performance considerations

Michael, On 12/11/06 10:57 AM, "Michael Stone" <[EMAIL PROTECTED]> wrote: > That's kinda the opposite of what I meant by general code. I was trying > (perhaps poorly) to distinguish between scientific codes and other > stuff (especially I/O or human interface code). Yes - choice of language has

Re: [PERFORM] New to PostgreSQL, performance considerations

At 02:28 PM 12/11/2006, Merlin Moncure wrote: also, some people posting here, not necessarily me, are authority figures. :-) merlin Noam Chomsky was one of the most influential thinkers in Linguistics to yet have lived. He was proven wrong a number of times. Even within Linguistics. Ther

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Dec 11, 2006 at 11:17:06AM -0200, Daniel van Ham Colchete wrote: > I just remebered one case with MySQL. When I changed the distro from > Conectiva 10 (rpm-based ended brazilian distro) to Gentoo, a MySQL > operation that usuall

Re: [PERFORM] New to PostgreSQL, performance considerations

At 01:47 PM 12/11/2006, Michael Stone wrote: On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote: (The validity of the claim has nothing to do with the skills or experience of the claimant or anyone else in the discussion. Only on the evidence.) Please go back and reread the original post. I

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Ron <[EMAIL PROTECTED]> wrote: Statements like these can not be reasonably interpreted in any manner _except_ that of presuming the results: "I expect that you'll discover, if you actually do these tests, that this belief (that using arch specific compiler options lead to better pe

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 10:30:55AM -0800, Luke Lonergan wrote: Here's one - I wrote a general purpose Computational Fluid Dynamics analysis method used by hundreds of people to perform aircraft and propulsion systems analysis. That's kinda the opposite of what I meant by general code. I was t

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 01:20:50PM -0500, Ron wrote: (The validity of the claim has nothing to do with the skills or experience of the claimant or anyone else in the discussion. Only on the evidence.) Please go back and reread the original post. I don't think the response was unwarranted.

Re: [PERFORM] New to PostgreSQL, performance considerations

Michael, On 12/11/06 9:31 AM, "Michael Stone" <[EMAIL PROTECTED]> wrote: > [1] I will say that I have never seen a realistic benchmark of general > code where the compiler flags made a statistically significant > difference in the runtime. Here's one - I wrote a general purpose Computational Flu

Re: [PERFORM] New to PostgreSQL, performance considerations

Statements like these can not be reasonably interpreted in any manner _except_ that of presuming the results: "I expect that you'll discover, if you actually do these tests, that this belief (that using arch specific compiler options lead to better performing SW) is fairly much nonsense." "

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 12:15:51PM -0500, Ron wrote: I'd say the fairest attitude is to do everything we can to support having the proper experiments done w/o presuming the results. Who's presuming results?[1] It is fair to say that making extraordinary claims without any evidence should be di

Re: [PERFORM] New to PostgreSQL, performance considerations

This definitely is the correct approach. Actually, Daniel van Ham Colchete may not be as "all wet" as some around here think. We've had previous data that shows that pg can become CPU bound (see previous posts by Josh Berkus and others regarding CPU overhead in what should be IO bound tasks).

Re: [PERFORM] New to PostgreSQL, performance considerations

[EMAIL PROTECTED] ("Daniel van Ham Colchete") writes: > You are right Christopher. > > Okay. Let's solve this matter. > > What PostgreSQL benchmark software should I use??? pgbench is one option. There's a TPC-W at pgFoundry (). There's the Open Sour

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Daniel van Ham Colchete <[EMAIL PROTECTED]> wrote: But, trust me on this one. It's worth it. Think of this: PostgreSQL and GNU LibC use a lot of complex algorithms: btree, hashes, checksums, strings functions, etc... And you have a lot of ways to compile it into binary code. Now you

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 11:31:48AM -0200, Daniel van Ham Colchete wrote: > What PostgreSQL benchmark software should I use??? Look up the list archives; search for "TPC". > I'll test PostgreSQL 8.1 on a Fedora Core 6 and on a Gentoo. I'll get > the same version FC6 uses and install it at my Gento

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 11:17:06AM -0200, Daniel van Ham Colchete wrote: > I just remebered one case with MySQL. When I changed the distro from > Conectiva 10 (rpm-based ended brazilian distro) to Gentoo, a MySQL > operation that usually took 2 minutes to run, ended in 47 seconds. How do you know

Re: [PERFORM] New to PostgreSQL, performance considerations

On 12/11/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Mon, Dec 11, 2006 at 11:09:13AM -0200, Daniel van Ham Colchete wrote: >> You know what? I don't. > So test it yourself. You're making the claims, you're supposed to be proving them... > As I said, it is an example. Take floatpoint

Re: [PERFORM] New to PostgreSQL, performance considerations

On Mon, Dec 11, 2006 at 11:09:13AM -0200, Daniel van Ham Colchete wrote: >> You know what? I don't. > So test it yourself. You're making the claims, you're supposed to be proving them... > As I said, it is an example. Take floatpoint divisions. You have > plenty of ways of doing it: 387, MMX, SSE

  1   2   >