Re: Bad performance on simple query - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Bad performance on simple query
Date
Msg-id dcc563d10811170940l3a2673a9o19f253b5b10c4c38@mail.gmail.com
Whole thread Raw
In response to Re: Bad performance on simple query  (Dimi Paun <dimi@lattica.com>)
Responses Re: Bad performance on simple query  (ries van Twisk <pg@rvt.dds.nl>)
Re: Bad performance on simple query  (Dimi Paun <dimi@lattica.com>)
List pgsql-performance
On Mon, Nov 17, 2008 at 10:31 AM, Dimi Paun <dimi@lattica.com> wrote:
>
> On Mon, 2008-11-17 at 10:16 -0700, Scott Marlowe wrote:
>> Ahhh.  Keep in mind that if you just run the query, pgadminIII will
>> tell you how long it took to run AND return all the data across the
>> network, so it will definitely take longer then.  But most of that's
>> network io wait so it's not a real issue unless you're saturating your
>> network.
>
> But that is brutal -- there's no way it can take 20ms for a request
> across an unloaded network.
>
> Moreover, I got something like this:
>
>            pgadminIII | pgsql
> w/o index:     45ms      0.620ms
> w/ index       20ms      0.091ms
>
> How now I try to replicate, and I get 45ms in both cases. This is
> very misleading...

I'm guessing a fair bit of that time is pgadminIII prettifying the
output for you, etc.  I.e. it's not all transfer time.  Hard to say
without hooking some kind of profiler in pgadminIII.  Is psql running
local and pgadminIII remotely?  Or are they both remote?  If both psql
and pgadminIII are remote (i.e. same basic circumstances) then it's
got to be a difference in the client causing the extra time.  OR is
this output of explain analyze?

pgsql-performance by date:

Previous
From: Dimi Paun
Date:
Subject: Re: Bad performance on simple query
Next
From: ries van Twisk
Date:
Subject: Re: Bad performance on simple query