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
>>
>>
>
