On 21/01/2011 19:12, gr...@amadensor.com wrote:
I was doing a little testing to see how machine load affected the
performance of different types of queries, index range scans, hash joins,
full scans, a mix, etc.
In order to do this, I isolated different performance hits, spinning only
CPU, loadi
>
> My guess is its something hypervisor related. If this happened on direct
> hardware I'd be more surprised. Hypervisors have all sorts of stuff going
> on, like throttling the number of CPU cycles a vm gets. In your idle
> case, your VM might effectively occupy 1Ghz of a CPU, but 2Ghz in the
>
> Odd. Did'ja by chance run the select more than once... maybe three or
> four times, and always get the same (or close) results?
>
> Is the stress package running niced?
>
> -Andy
>
I got a little crazy, and upgraded the DB to 8.4.5. It still reacts the
same.
I am hoping someone has an idea
On 1/21/11 12:23 PM, "gr...@amadensor.com" wrote:
>> gr...@amadensor.com writes:
>>> Here is the fun part. When running 8 threads spinning calculating
>>> square
>>> roots (using the stress package), the full scan returned consistently
>>> 60%
>>> faster than the machine with no load.
>>
>> P
> gr...@amadensor.com writes:
>> Here is the fun part. When running 8 threads spinning calculating
>> square
>> roots (using the stress package), the full scan returned consistently
>> 60%
>> faster than the machine with no load.
>
> Possibly the synchronized-seqscans logic kicking in, resulting
>
> Odd. Did'ja by chance run the select more than once... maybe three or
> four times, and always get the same (or close) results?
>
> Is the stress package running niced?
>
The stress package is not running niced. I ran it initially 5 times each.
It was very consistent. Initially, I just ran
gr...@amadensor.com wrote:
This was on a 4 CPU Xen virtual machine running
8.1.22 on CENTOS.
You're not going to get anyone to spend a minute trying to figure what's
happening on virtual hardware with an ancient version of PostgreSQL. If
this was an actual full test case against PostgreSQ
gr...@amadensor.com writes:
> Here is the fun part. When running 8 threads spinning calculating square
> roots (using the stress package), the full scan returned consistently 60%
> faster than the machine with no load.
Possibly the synchronized-seqscans logic kicking in, resulting in this
guy no
On 1/21/2011 12:12 PM, gr...@amadensor.com wrote:
I was doing a little testing to see how machine load affected the
performance of different types of queries, index range scans, hash joins,
full scans, a mix, etc.
In order to do this, I isolated different performance hits, spinning only
CPU, loa
I was doing a little testing to see how machine load affected the
performance of different types of queries, index range scans, hash joins,
full scans, a mix, etc.
In order to do this, I isolated different performance hits, spinning only
CPU, loading the disk to create high I/O wait states, and us
10 matches
Mail list logo
