On 1/21/2011 12:12 PM, grant@xxxxxxxxxxxxx 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, loading the disk to create high I/O wait states, and using most of
the physical memory. This was on a 4 CPU Xen virtual machine running
8.1.22 on CENTOS.
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. It was returning 44,000 out of
5,000,000 rows. Here is the explain analyze. I am hoping that this
triggers something (I can run more tests as needed) that can help us make
it always better.
Idling:
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Seq Scan on schedule_details (cost=0.00..219437.90 rows=81386 width=187)
(actual time=0.053..2915.966 rows=44320 loops=1)
Filter: (schedule_type = '5X'::bpchar)
Total runtime: 2986.764 ms
Loaded:
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Seq Scan on schedule_details (cost=0.00..219437.90 rows=81386 width=187)
(actual time=0.034..1698.068 rows=44320 loops=1)
Filter: (schedule_type = '5X'::bpchar)
Total runtime: 1733.084 ms
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
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
