[qjighap]

These articles drive me crazy when they don't mention the testing process. Yes, he is using a "server class" machine, but did he disable the features on a hardware level that would skew the test. Answer: probably. I'll assume he did some sort of clear to makes sure that the data wasn't cached on the hard drive or assume that all the reads were in memory. I can't even tell if he ran the test over several iterations.

It isn't that I am doubting the results, but without some trail on how to get the results I can't make this useful information. For example if I were architecting a system and was using this as information I have no idea if I run this in a VM that I need enough memory to get these results.

[mohaine]

Did you read the article?

Quote:

To start with let us see the impact of work done to improve the performance of hash indexes. Below is the performance data of the pgbench read-only workload to compare the performance difference of Hash indexes between 9.6 and HEAD on IBM POWER-8 having 24 cores, 192 hardware threads, 492GB RAM.

The workload is such that all the data fits in shared buffers (scale factor is 300 (~4.5GB) and shared_buffers is 8GB).

And chart itself says it is a median of 3 5 minute runs.

[qjighap]

I believe I did.

Why would I assume that Concurrent runs == Seperate Runs or that other caching mechanisms aren't in place or really anything. Computers do really odd things trying to optimize and making assumptions that your system is the same over a period of 30 minutes when you don't even know it is the same 30 minutes is concurrent. There is all sorts of stuff that gets in the way of performance tests and I would like to know how it is mitigated. Again, I am sure there is proper process, but why wouldn't know want to know what that is?