X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2E31056616 for ; Fri, 11 Mar 2005 20:35:32 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 63693-04 for ; Fri, 11 Mar 2005 20:35:22 +0000 (GMT) Received: from mesagate.talleyds.com (unknown [207.114.138.130]) by svr1.postgresql.org (Postfix) with ESMTP id 460A85661A for ; Fri, 11 Mar 2005 20:35:20 +0000 (GMT) Received: from TDS-MTA by mesagate.talleyds.com with Novell_GroupWise; Fri, 11 Mar 2005 13:35:22 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Fri, 11 Mar 2005 13:35:03 -0700 From: "Lou O'Quin" To: Cc: Subject: Re: Query performance Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartFFDC82E7.0__=" X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.384 tagged_above=0 required=5 tests=AWL, HTML_20_30, HTML_MESSAGE X-Spam-Level: X-Archive-Number: 200503/197 X-Sequence-Number: 10902 --=__PartFFDC82E7.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'll post there concerning how they determine the query execution time vs. = data retrieval time. =20 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 =20 Lou >>> Tom Lane 3/11/2005 1:21 PM >>> "Lou O'Quin" 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 --=__PartFFDC82E7.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Description: HTML

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
&n= bsp; joining column's datatypes do not match

--=__PartFFDC82E7.0__=--