Skip site navigation (1) Skip section navigation (2)

Re: Joins and full index scans...mysql vs postgres?

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: ryan groth <postgres(at)cpusoftware(dot)com>
Cc: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>,"Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: Joins and full index scans...mysql vs postgres?
Date: 2006-02-23 02:52:11
Message-ID: 43FD235B.7000207@familyhealth.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
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
>>
>>
> 


In response to

Responses

pgsql-performance by date

Next:From: Greg StarkDate: 2006-02-23 03:52:48
Subject: Re: Good News re count(*) in 8.1
Previous:From: ChrisDate: 2006-02-22 23:58:39
Subject: Re: Joins and full index scans...mysql vs postgres?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group