Re: Joel's Performance Issues WAS : Opteron vs Xeon
От | Tom Lane |
---|---|
Тема | Re: Joel's Performance Issues WAS : Opteron vs Xeon |
Дата | |
Msg-id | 11216.1114058132@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Joel's Performance Issues WAS : Opteron vs Xeon (John A Meinel <john@arbash-meinel.com>) |
Ответы |
Re: Joel's Performance Issues WAS : Opteron vs Xeon
|
Список | pgsql-performance |
John A Meinel <john@arbash-meinel.com> writes: > Joel Fradkin wrote: >> Postgres was on the second run >> Total query runtime: 17109 ms. >> Data retrieval runtime: 72188 ms. >> 331640 rows retrieved. > How were you measuring "data retrieval time"? I suspect he's using pgadmin. We've seen reports before suggesting that pgadmin can be amazingly slow, eg here http://archives.postgresql.org/pgsql-performance/2004-10/msg00427.php where the *actual* data retrieval time as shown by EXPLAIN ANALYZE was under three seconds, but pgadmin claimed the query runtime was 22 sec and data retrieval runtime was 72 sec. I wouldn't be too surprised if that time was being spent formatting the data into a table for display inside pgadmin. It is a GUI after all, not a tool for pushing vast volumes of data around. It'd be interesting to check the runtimes for the same query with LIMIT 3000, ie, see if a tenth as much data takes a tenth as much processing time or not. The backend code should be pretty darn linear in this regard, but maybe pgadmin isn't. regards, tom lane
В списке pgsql-performance по дате отправления: