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)
Ответы Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin")
Список pgsql-performance
Дерево обсуждения
Re: Opteron vs Xeon (Was: What to do with 6 disks?)  ("Anjan Dave", )
 Re: Opteron vs Xeon (Was: What to do with 6 disks?)  ("Joel Fradkin", )
  Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Josh Berkus, )
   Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
    Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Josh Berkus, )
     Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Vivek Khera, )
    Re: Joel's Performance Issues WAS : Opteron vs Xeon  (John A Meinel, )
     Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
      Re: Joel's Performance Issues WAS : Opteron vs Xeon  (John A Meinel, )
       Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Tom Lane, )
        Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
       Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Joel Fradkin", )
        Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby", )
         Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Kevin Brown, )
          Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Josh Berkus, )
           Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Kevin Brown, )
            Re: Joel's Performance Issues WAS : Opteron vs Xeon  ("Jim C. Nasby", )
      Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Josh Berkus, )
      Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Andreas Pflug, )
John A Meinel <> 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 по дате отправления:

Предыдущее
От: "David Roussel"
Дата:
Сообщение: How can an index be larger than a table
Следующее
От: "Shoaib Burq (VPAC)"
Дата:
Сообщение: two queries and dual cpu (perplexed)