Re: Query performance - Mailing list pgsql-performance

From Lou O'Quin
Subject Re: Query performance
Date
Msg-id s2319e9a.045@mesagate.talleyds.com
Whole thread Raw
In response to Query performance  ("Lou O'Quin" <loquin@talleyds.com>)
List pgsql-performance
I'll post there concerning how they determine the query execution time vs. data retrieval time.
 
I did think about the processor/memory when choosing the machines - all three of the processors are similar.  All are Pentium P4s with 512 MB memory.
the server is Win2K, P4, 2.3 gHz
the local network client  is a WinXP Pro, P4, 2.2 gHz
the remote network client is WinXP Pro, P4, 1.9 gHz
 
Lou

>>> Tom Lane <tgl@sss.pgh.pa.us> 3/11/2005 1:21 PM >>>
"Lou O'Quin" <loquin@talleyds.com> writes:
> Hi Tom.  I referenced the status line of pgAdmin.  Per the pgAdmin help
> file:
>
> "The status line will show how long the last query took to complete. If a
> dataset was returned, not only the elapsed time for server execution is
> displayed, but also the time to retrieve the data from the server to the
> Data Output page."

Well, you should probably ask the pgadmin boys exactly what they are
measuring.  In any case, the Postgres server overlaps query execution
with result sending, so I don't think it's possible to get a pure
measurement of just one of those costs --- certainly not by looking at
it only from the client end.

BTW, one factor to consider is that if the test client machines weren't
all the same speed, that would have some impact on their ability to
absorb 15K records ...

            regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Questions about 2 databases.
Next
From: Richard_D_Levine@raytheon.com
Date:
Subject: Re: Questions about 2 databases.