The pgAdmin query tool is known to give an answer about 5x the real
answer - don't believe it!
ryan groth wrote:
Hmm, it came from the timer on the pgadmin III sql query tool. I guess
the 1,000ms includes the round-trip? See the wierd thing is that
mysqlserver is running default configuration on a virtual machine
(P3/1.3GHZ conf'd for 128mb ram) over a 100m/b ethernet connection.
Postgres is running on a real P4/3.0ghz 4GB running localhost. Timings
from the mysql query tool indicate that the 6.5k record query runs in
"1.3346s (.3361s)" vs. the pgadmin query tool saying that the query runs
"997+3522 ms". Am I reading these numbers wrong? Are these numbers
reflective of application performance? Is there an optimization I am
missing?
Ryan
On Wed, 22 Feb 2006, ryan groth wrote:
Does this work:
"Merge Left Join (cost=0.00..2656.36 rows=6528 width=1522) (actual
time=0.057..123.659 rows=6528 loops=1)"
" Merge Cond: ("outer".uid = "inner".uid)"
" -> Merge Left Join (cost=0.00..1693.09 rows=6528 width=1264)
(actual time=0.030..58.876 rows=6528 loops=1)"
" Merge Cond: ("outer".uid = "inner".user_id)"
" -> Index Scan using users_pkey on users (cost=0.00..763.81
rows=6528 width=100) (actual time=0.016..9.446 rows=6528 loops=1)"
" -> Index Scan using phorum_users_base_pkey on
phorum_users_base (cost=0.00..822.92 rows=9902 width=1168) (actual
time=0.007..15.674 rows=9845 loops=1)"
" -> Index Scan using useraux_pkey on useraux (cost=0.00..846.40
rows=7582 width=262) (actual time=0.007..11.935 rows=7529 loops=1)"
"Total runtime: 127.442 ms"
Well, this implies the query took about 127 ms on the server side. Where
did the 1000 ms number come from (was that on a client, and if so, what
type)?
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
