----- Original Message -----
Sent: Tuesday, March 11, 2003 3:46
AM
Subject: Re: [PERFORM] Large difference
between elapsed time and run time
Hi,
I have noted similar issues in the past - and seemed then that
most of the overhead bottleneck was due to establishing a new connection in
the front end. As soon as I started using connection pooling, with
connections made when the app initialises, and then recycled for each request
(i.e. the connections never close) then the execution time was far quicker.
I have also noticed that sparc processor speed, num
processors, disk space and memory seems to makes little difference with
postgres (for us anyway!) performance - e.g. performance no better with dual
sparc 450mhz, 2 scsi disks, 1Gb mem - than on a single processor 400 mhz
Netra, 256Mb ram with a single IDE disk!
Nikk
-----Original Message-----
From: Scott
Buchan [mailto:sbuchan(at)technicacorp(dot)com]
Sent: 10 March 2003 18:58
To:
pgsql-performance(at)postgresql(dot)org
Subject: [PERFORM]
Large difference between elapsed time and run time for queries
Hello,
While running benchmarks for my database, I am seeing a large
difference in the elapsed time (from stats collected in the logs) and run time
(running explain analyze on the query using ./psql <database>) for each
of my queries. The database is being ran on a sunfire 880 with 4 750mhz
processors with 8 G RAM running solaris 8
I am simulating 200 user connections each running 6 select
queries on 1 indexed table with 50,000 records. The elapsed time for the
queries average around 2.5 seconds while if I run the query using explain
analyze while the test is running, the run time is around 300 ms although it
takes much longer (few seconds) to display the results. If I reduce the
number of concurrent connections to 100 then the run time and elapsed time for
the queries are the same.
I have tried numerous configurations in the postgresql.conf
file. I have set the shared_buffers with values ranging from 75 MB to
4000MB with no luck. I have also tried increasing the sort_mem with no
luck.
When the test is running, the cpu is well over 50% idle and
iostat shows that the processes are not waiting for i/o and disk usage
percentage is low.
Any help would be appreciated.
Thanks.