Re: Joel's Performance Issues WAS : Opteron vs Xeon

От: Jim C. Nasby
Тема: Re: Joel's Performance Issues WAS : Opteron vs Xeon
Дата: ,
Msg-id: 20050427210150.GB58835@decibel.org
(см: обсуждение, исходный текст)
Ответ на: Re: Joel's Performance Issues WAS : Opteron vs Xeon  (Kevin Brown)
Список: 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, )

BTW, http://stats.distributed.net/~decibel/base.log is a test I ran;
select count(*) was ~6x faster than explain analyze select *.

On Tue, Apr 26, 2005 at 07:46:52PM -0700, Kevin Brown wrote:
> Josh Berkus wrote:
> > Jim, Kevin,
> >
> > > > Hrm... I was about to suggest that for timing just the query (and not
> > > > output/data transfer time) using explain analyze, but then I remembered
> > > > that explain analyze can incur some non-trivial overhead with the timing
> > > > calls. Is there a way to run the query but have psql ignore the output?
> > > > If so, you could use \timing.
> > >
> > > Would timing "SELECT COUNT(*) FROM (query)" work?
> >
> > Just \timing would work fine; PostgreSQL doesn't return anything until it has
> > the whole result set.
>
> Hmm...does \timing show the amount of elapsed time between query start
> and the first results handed to it by the database (even if the
> database itself has prepared the entire result set for transmission by
> that time), or between query start and the last result handed to it by
> the database?
>
> Because if it's the latter, then things like server<->client network
> bandwidth are going to affect the results that \timing shows, and it
> won't necessarily give you a good indicator of how well the database
> backend is performing.  I would expect that timing SELECT COUNT(*)
> FROM (query) would give you an idea of how the backend is performing,
> because the amount of result set data that has to go over the wire is
> trivial.
>
> Each is, of course, useful in its own right, and you want to be able
> to measure both (so, for instance, you can get an idea of just how
> much your network affects the overall performance of your queries).
>
>
> > That's why MSSQL vs. PostgreSQL timing comparisons are
> > deceptive unless you're careful:  MSSQL returns the results on block at a
> > time, and reports execution time as the time required to return the *first*
> > block, as opposed to Postgres which reports the time required to return the
> > whole dataset.
>
> Interesting.  I had no idea MSSQL did that, but I can't exactly say
> I'm surprised.  :-)
>
>
> --
> Kevin Brown                          
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to  so that your
>       message can get through to the mailing list cleanly
>

--
Jim C. Nasby, Database Consultant               
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


В списке pgsql-performance по дате сообщения:

От: Josh Berkus
Дата:
Сообщение: Re: Why is this system swapping?
От: Josh Berkus
Дата:
Сообщение: Re: Final decision