From rhahn@docfocus.ca Mon Apr  30 18:32:48 2012
Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 49A2DD32489
	for <pgsql-performance@postgresql.org>;
	Mon, 30 Apr 2012 15:32:48 -0300 (ADT)
Received: from mail.amadorgroup.biz ([64.42.211.250] helo=amadorgroup.biz)
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <rhahn@docfocus.ca>) id 1SOvOw-0004XZ-SV
	for pgsql-performance@postgresql.org; Mon, 30 Apr 2012 18:32:47 +0000
X-MDAV-Processed: amadorgroup.biz, Mon, 30 Apr 2012 12:32:30 -0600
Received: from [172.17.2.104] by amadorgroup.biz (MDaemon PRO v12.5.4)
	with ESMTP id md50003194531.msg
	for <pgsql-performance@postgresql.org>; Mon, 30 Apr 2012 12:32:29 -0600
X-Spam-Processed: amadorgroup.biz, Mon, 30 Apr 2012 12:32:29 -0600
	(not processed: message from trusted or authenticated source)
X-Authenticated-Sender: rhahn@docfocus.ca
X-MDRemoteIP: 172.17.2.104
X-Return-Path: rhahn@docfocus.ca
X-Envelope-From: rhahn@docfocus.ca
X-MDaemon-Deliver-To: pgsql-performance@postgresql.org
Message-ID: <4F9EDACA.4010901@docfocus.ca>
Date: Mon, 30 Apr 2012 12:32:42 -0600
From: "Ronald Hahn, DOCFOCUS INC." <rhahn@docfocus.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Result Set over Network Question
Content-Type: multipart/alternative;
	boundary="------------030600060603050705010106"
X-Pg-Spam-Score: -0.9 (/)
X-Archive-Number: 201205/19
X-Sequence-Number: 46843

This is a multi-part message in MIME format.
--------------030600060603050705010106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,
     We have recently switch our product from MS SQL 2000 to Postgresql 
9.0.7. We have tuned the searches and indexes so that they are very 
close (often better) to what sql2k was giving us.  We are noticing some 
differences now in the time it takes for the result set to make it back 
to the client and would like some help finding out why.

What we see on the PG side is that if we run:
     Select SomeInt32 from someTable where something Limit 1
It consistently returns the results "instantaneously"  after the fetch 
time.  If we run the same select but ask for more data the fetch time 
stays the same but the row takes longer to come back.  Bringing back 400 
bytes takes 1-2 s but bringing back 866 bytes takes 9 - 11 s.

We went to the SQL2k server (On the same hardware) and ran the selects 
again. When bringing back on an int32 PG was faster with the fetch and 
the row coming back in 1-5 ms and SQL2k coming back in 500-700 ms. This 
tells me that the problem is not related to PG index or Disk.  When 
bringing back 400 bytes PG fetch time would be 1-2 ms but the results 
would take 2-3 s but SQL2k would it bring back in 700-900 ms. Working 
with 866 bytes, PG fetch time is 1-3 ms with the results coming back in 
9 - 11 s and SQL2k bringing the results back in 2-3 s.

The head to head test was run in Aqua Data Studio 10.0.8 and ODBC driver 
9.0.3.10. The same slow down happens when use PGadminIII. The differnces 
in time to not occure when running on the pg/sql server computer so I 
think there is a network component to this.

I know that as you bring back more data it takes longer but why is there 
such a difference in the time it takes PG to send the data compared to 
the time it takes sql2k to send it?

Any thoughts and suggestions are very much appreciated
Thanks
Ron
-- 

*Ronald Hahn* , CCP, CIPS Member
*DOCFOCUS INC.*
Suite 103, 17505 - 107 Avenue,
Edmonton, Alberta T5S 1E5
Phone: 780.444.5407
Toll Free: 800.661.2727 (ext 6)
Fax: 780.444.5409
Email: rhahn@docfocus.ca
Support:dfisupport@docfocus.ca <mailto:dfisupport@docfocus.ca>
DOCFOCUS.ca <http://docfocus.ca/>

There are 2 kinds of people in the world.
Those who can extrapolate from incomplete data


--------------030600060603050705010106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi, <br>
    &nbsp;&nbsp;&nbsp; We have recently switch our product from MS SQL 2000 to
    Postgresql 9.0.7. We have tuned the searches and indexes so that
    they are very close (often better) to what sql2k was giving us.&nbsp; We
    are noticing some differences now in the time it takes for the
    result set to make it back to the client and would like some help
    finding out why.<br>
    <br>
    What we see on the PG side is that if we run:<br>
    &nbsp;&nbsp;&nbsp; Select SomeInt32 from someTable where something Limit 1 <br>
    It consistently returns the results "instantaneously"&nbsp; after the
    fetch time.&nbsp; If we run the same select but ask for more data the
    fetch time stays the same but the row takes longer to come back.&nbsp;
    Bringing back 400 bytes takes 1-2 s but bringing back 866 bytes
    takes 9 - 11 s. <br>
    <br>
    We went to the SQL2k server (On the same hardware) and ran the
    selects again. When bringing back on an int32 PG was faster with the
    fetch and the row coming back in 1-5 ms and SQL2k coming back in
    500-700 ms. This tells me that the problem is not related to PG
    index or Disk.&nbsp; When bringing back 400 bytes PG fetch time would be
    1-2 ms but the results would take 2-3 s but SQL2k would it bring
    back in 700-900 ms. Working with 866 bytes, PG fetch time is 1-3 ms
    with the results coming back in 9 - 11 s and SQL2k bringing the
    results back in 2-3 s.<br>
    <br>
    The head to head test was run in Aqua Data Studio 10.0.8 and ODBC
    driver 9.0.3.10. The same slow down happens when use PGadminIII. The
    differnces in time to not occure when running on the pg/sql server
    computer so I think there is a network component to this.<br>
    <br>
    I know that as you bring back more data it takes longer but why is
    there such a difference in the time it takes PG to send the data
    compared to the time it takes sql2k to send it?&nbsp; <br>
    <br>
    Any thoughts and suggestions are very much appreciated <br>
    Thanks<br>
    Ron<br>
    <div class="moz-signature">-- <br>
      <meta http-equiv="CONTENT-TYPE" content="text/html;
        charset=ISO-8859-1">
      <title>Signature</title>
      <meta name="GENERATOR" content="OpenOffice.org 3.0 (Unix)">
      <meta name="CREATED" content="0;0">
      <meta name="CHANGEDBY" content="Ronald Hahn">
      <meta name="CHANGED" content="20090526;13112700">
      <meta name="CHANGEDBY" content="Ronald Hahn">
      <p style="margin-bottom: 0cm" align="LEFT"><font face="Courier
          New"><font size="2"><b>Ronald Hahn</b></font></font>
        <font face="Courier New"><font style="font-size: 9pt" size="2"><span
              style="font-weight: normal">, CCP, CIPS Member</span></font></font>
        <font face="Courier New"><font size="2"><br>
          </font></font><font color="#993366"><font face="Courier New"><font
              size="2"><b>DOCFOCUS INC.</b></font></font></font>
        <font face="Courier New"><font size="2"><br>
            Suite 103, 17505 - 107 Avenue, <br>
            Edmonton, Alberta T5S 1E5<br>
            Phone: 780.444.5407<br>
            Toll Free: 800.661.2727 (ext 6)<br>
            Fax: 780.444.5409 <br>
            Email: <a class="moz-txt-link-abbreviated" href="mailto:rhahn@docfocus.ca">rhahn@docfocus.ca</a><br>
            Support:<a href="mailto:dfisupport@docfocus.ca">dfisupport@docfocus.ca</a>
            <br>
            <a href="http://docfocus.ca/">DOCFOCUS.ca</a>
            <br>
            <br>
            There are 2 kinds of people in the world. <br>
            Those who can extrapolate from incomplete data
          </font></font></p>
    </div>
  </body>
</html>

--------------030600060603050705010106--




From klaussfreire@gmail.com Thu May  3 14:28:37 2012
Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id C9D161C2F15
	for <pgsql-performance@postgresql.org>;
	Thu,  3 May 2012 11:28:37 -0300 (ADT)
Received: from mail-lpp01m010-f46.google.com ([209.85.215.46])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <klaussfreire@gmail.com>) id 1SPx1D-00050H-4X
	for pgsql-performance@postgresql.org; Thu, 03 May 2012 14:28:36 +0000
Received: by lahj13 with SMTP id j13so1279646lah.19
	for <pgsql-performance@postgresql.org>;
	Thu, 03 May 2012 07:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=7Yo1T24n8nK6yWfI/mpCVdYUvrN+sogSdvdJydsxywM=;
	b=OOC7kNLUYn2on39JvVZSF+9YfZVlXvc/a3WKeLjY2z0lpuCjtea7OWAO+s3QabnX3p
	9jimvsf2b0pA4F7BEpM/TbTaxfOJw6JxU7jNLGpv51g5JkcvWPSkYy/x9/AQMUXoFlg6
	MXHlZOlLKAfh7EBkTfDkV8bVB6jDD+jA1qpCciGAbdnNrIxdV1ypekTivoG6Q/qOYx03
	D7RAKnSO8Oe10ujdpIZ1snc/NEhlGgFzKtLcqsMbjYKECAgH8r0n0Gj9SWKrMKjWdGWR
	haaEGR3VzL7TjxGJxpPuSZKO+Dovgq6AavbE/db0vMsjCxkBHW6NibE8tyxsODF+kJ/M
	T+XQ==
MIME-Version: 1.0
Received: by 10.112.9.130 with SMTP id z2mr1149226lba.83.1336055298137; Thu,
	03 May 2012 07:28:18 -0700 (PDT)
Received: by 10.112.24.8 with HTTP; Thu, 3 May 2012 07:28:18 -0700 (PDT)
In-Reply-To: <4F9EDACA.4010901@docfocus.ca>
References: <4F9EDACA.4010901@docfocus.ca>
Date: Thu, 3 May 2012 11:28:18 -0300
Message-ID: 
 <CAGTBQpZ-J_y1Wxq8f8=2KVHoaA_zOr26_Y12B4OzkZt1kD=7=Q@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Claudio Freire <klaussfreire@gmail.com>
To: "Ronald Hahn, DOCFOCUS INC." <rhahn@docfocus.ca>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Pg-Spam-Score: -2.7 (--)
X-Archive-Number: 201205/31
X-Sequence-Number: 46855

On Mon, Apr 30, 2012 at 3:32 PM, Ronald Hahn, DOCFOCUS INC.
<rhahn@docfocus.ca> wrote:
> We went to the SQL2k server (On the same hardware) and ran the selects
> again. When bringing back on an int32 PG was faster with the fetch and th=
e
> row coming back in 1-5 ms and SQL2k coming back in 500-700 ms. This tells=
 me
> that the problem is not related to PG index or Disk.=A0 When bringing bac=
k 400
> bytes PG fetch time would be 1-2 ms but the results would take 2-3 s but
> SQL2k would it bring back in 700-900 ms. Working with 866 bytes, PG fetch
> time is 1-3 ms with the results coming back in 9 - 11 s and SQL2k bringin=
g
> the results back in 2-3 s.

I think the opposite. I'm thinking it's quite probable that it's disk
access the one killing you. Remember, two different database systems
means two different access patterns.

To figure it out, you have to provide a lot more information on your
system and your query. Check out how to post "Slow Query Questions"
[0]. Only after getting all that information the people of the list
will be able to have a clue as to what your problem is.

[0] http://wiki.postgresql.org/wiki/SlowQueryQuestions



From mmoncure@gmail.com Thu May  3 15:01:13 2012
Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id C78381C2F15
	for <pgsql-performance@postgresql.org>;
	Thu,  3 May 2012 12:01:13 -0300 (ADT)
Received: from mail-pb0-f46.google.com ([209.85.160.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <mmoncure@gmail.com>) id 1SPxWq-00058U-Qg
	for pgsql-performance@postgresql.org; Thu, 03 May 2012 15:01:13 +0000
Received: by pbbrp8 with SMTP id rp8so2590840pbb.19
	for <pgsql-performance@postgresql.org>;
	Thu, 03 May 2012 08:01:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=KbMHHG0X63FmoHVGzpmEUha+pzUBu+lc17Dp4r7v1fw=;
	b=TUy3YxVEfrPCcmgMr1qIuD4ZmUI+blaL5hpX84uJqrom5yoO0rPc/0LMiVW/GkD0oj
	oUAdwCypoehYJphxVkaVbqjleMU1fvh67CwP3bZU4+DeXrJrcz5NxaGCVW7cP0LG9ScA
	6SUBtlQLY0R1kRFAmE6fx81ywo9oMZvQpKIyeq0QI79X/6abhhdPBczCXkBE4gKB6l6l
	ET9CwpCui/HBhM7bO2gyjuZjy1DGHIzLh9XSNhyER3oVbxqvyRyYvfTTelccgzwQcwON
	hAkelgrEDOz3ctbUR3phBopmk5L6UnTDFtxgOSqmSV4VQEa6oUAbqI2mOCO+FdE0oDmH
	fn5Q==
MIME-Version: 1.0
Received: by 10.68.201.234 with SMTP id kd10mr137058pbc.116.1336057259969;
	Thu, 03 May 2012 08:00:59 -0700 (PDT)
Received: by 10.143.2.4 with HTTP; Thu, 3 May 2012 08:00:59 -0700 (PDT)
In-Reply-To: <4F9EDACA.4010901@docfocus.ca>
References: <4F9EDACA.4010901@docfocus.ca>
Date: Thu, 3 May 2012 10:00:59 -0500
Message-ID: 
 <CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Merlin Moncure <mmoncure@gmail.com>
To: "Ronald Hahn, DOCFOCUS INC." <rhahn@docfocus.ca>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201205/32
X-Sequence-Number: 46856

On Mon, Apr 30, 2012 at 1:32 PM, Ronald Hahn, DOCFOCUS INC.
<rhahn@docfocus.ca> wrote:
> Hi,
> =A0=A0=A0 We have recently switch our product from MS SQL 2000 to Postgre=
sql
> 9.0.7. We have tuned the searches and indexes so that they are very close
> (often better) to what sql2k was giving us.=A0 We are noticing some
> differences now in the time it takes for the result set to make it back t=
o
> the client and would like some help finding out why.
>
> What we see on the PG side is that if we run:
> =A0=A0=A0 Select SomeInt32 from someTable where something Limit 1
> It consistently returns the results "instantaneously"=A0 after the fetch
> time.=A0 If we run the same select but ask for more data the fetch time s=
tays
> the same but the row takes longer to come back.=A0 Bringing back 400 byte=
s
> takes 1-2 s but bringing back 866 bytes takes 9 - 11 s.
>
> We went to the SQL2k server (On the same hardware) and ran the selects
> again. When bringing back on an int32 PG was faster with the fetch and th=
e
> row coming back in 1-5 ms and SQL2k coming back in 500-700 ms. This tells=
 me
> that the problem is not related to PG index or Disk.=A0 When bringing bac=
k 400
> bytes PG fetch time would be 1-2 ms but the results would take 2-3 s but
> SQL2k would it bring back in 700-900 ms. Working with 866 bytes, PG fetch
> time is 1-3 ms with the results coming back in 9 - 11 s and SQL2k bringin=
g
> the results back in 2-3 s.
>
> The head to head test was run in Aqua Data Studio 10.0.8 and ODBC driver
> 9.0.3.10. The same slow down happens when use PGadminIII. The differnces =
in
> time to not occure when running on the pg/sql server computer so I think
> there is a network component to this.

to rule out network just do:
create temp table scratch as select <your query>...

if it's a lot faster, then you have a probable network issue.

merlin



From rhahn@docfocus.ca Thu May  3 15:28:52 2012
Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 93BEB1C2F15
	for <pgsql-performance@postgresql.org>;
	Thu,  3 May 2012 12:28:52 -0300 (ADT)
Received: from mail.amadorgroup.biz ([64.42.211.250] helo=amadorgroup.biz)
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <rhahn@docfocus.ca>) id 1SPxxZ-0006V2-An
	for pgsql-performance@postgresql.org; Thu, 03 May 2012 15:28:51 +0000
X-MDAV-Processed: amadorgroup.biz, Thu, 03 May 2012 09:28:31 -0600
Received: from [172.17.2.104] by amadorgroup.biz (MDaemon PRO v12.5.4)
	with ESMTP id md50003199144.msg
	for <pgsql-performance@postgresql.org>; Thu, 03 May 2012 09:28:30 -0600
X-Spam-Processed: amadorgroup.biz, Thu, 03 May 2012 09:28:30 -0600
	(not processed: message from trusted or authenticated source)
X-Authenticated-Sender: rhahn@docfocus.ca
X-MDRemoteIP: 172.17.2.104
X-Return-Path: rhahn@docfocus.ca
X-Envelope-From: rhahn@docfocus.ca
X-MDaemon-Deliver-To: pgsql-performance@postgresql.org
Message-ID: <4FA2A42C.9090900@docfocus.ca>
Date: Thu, 03 May 2012 09:28:44 -0600
From: "Ronald Hahn, DOCFOCUS INC." <rhahn@docfocus.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Result Set over Network Question
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
In-Reply-To: 
 <CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------090007030107090700000208"
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201205/33
X-Sequence-Number: 46857

This is a multi-part message in MIME format.
--------------090007030107090700000208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

After some testing using wiershark (poor mans profiler) to see what was 
going on with the network I found that it was the tools I've been using. 
Both Aqua and PGadminIII have a large overhead per column to get the 
meta data. MSSQL sends that data upfront so the impact isn't as bad. I'm 
not sure if it's a limitation of the pgsql protocol vs tds or a 
limitation of Aqua or a combination of both. At any rate it turns out 
not to be part of the problem I'm having with my software stalling out 
so I'm back to Square one with my problem.

Thanks,
Ron


--------------090007030107090700000208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    After some testing using wiershark (poor mans <span style="color:
      rgb(0, 0, 0); font-family: Arial, 'Liberation Sans', 'DejaVu
      Sans', sans-serif; font-size: 14px; font-style: normal;
      font-variant: normal; font-weight: normal; letter-spacing: normal;
      line-height: 18px; orphans: 2; text-align: left; text-indent: 0px;
      text-transform: none; white-space: normal; widows: 2;
      word-spacing: 0px; -webkit-text-size-adjust: auto;
      -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
      255); display: inline !important; float: none; ">profiler<span
        class="Apple-converted-space"></span></span>) to see what was
    going on with the network I found that it was the tools I've been
    using. Both Aqua and PGadminIII have a large overhead per column to
    get the meta data. MSSQL sends that data upfront so the impact isn't
    as bad. I'm not sure if it's a limitation of the pgsql protocol vs
    tds or a limitation of Aqua or a combination of both. At any rate it
    turns out not to be part of the problem I'm having with my software
    stalling out so I'm back to Square one with my problem.<br>
    <br>
    Thanks, <br>
    Ron<br>
    <br>
  </body>
</html>

--------------090007030107090700000208--




From mmoncure@gmail.com Thu May  3 15:40:40 2012
Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 3968D1C2F15
	for <pgsql-performance@postgresql.org>;
	Thu,  3 May 2012 12:40:40 -0300 (ADT)
Received: from mail-pb0-f46.google.com ([209.85.160.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <mmoncure@gmail.com>) id 1SPy90-0005yn-VX
	for pgsql-performance@postgresql.org; Thu, 03 May 2012 15:40:39 +0000
Received: by pbbrp8 with SMTP id rp8so2633797pbb.19
	for <pgsql-performance@postgresql.org>;
	Thu, 03 May 2012 08:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=PzDrdTCJLIVRik/wFtiImE9mXfyyAEy26C+c6FwvVPY=;
	b=GEz406eeC8S57ISZlKVfioqHHP/SJddvpl35efFZGQVlH9qKl3URM/AeyVjvs8rgTn
	w9E+cSubHmu+bxWNkjB8vcPITokiN2Ppj2I4X6BRYWZs1LT0dEx94dkNoD7eE0pBydmd
	gvKcQBRv3AH0yHucVkxpr+W0vCmYn7xYw4IQpzx88DcmZKqlR+AL1HU+OqM4zEvbQQa9
	p+bs2DHl2zkaTjTUFSRmX2ZNT3Z+Xl930q490og+ye3136Io69XKAeMXFWWFWy2h73nl
	OsmpHcsDBRLU+XFL4Qsjb/+VqqimJNgfVf7lDeypaut4beWidDzpFlZqoDu4AgX0qnqw
	NIDQ==
MIME-Version: 1.0
Received: by 10.68.134.8 with SMTP id pg8mr8664827pbb.152.1336059626071; Thu,
	03 May 2012 08:40:26 -0700 (PDT)
Received: by 10.143.2.4 with HTTP; Thu, 3 May 2012 08:40:26 -0700 (PDT)
In-Reply-To: <4FA2A42C.9090900@docfocus.ca>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
Date: Thu, 3 May 2012 10:40:26 -0500
Message-ID: 
 <CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Merlin Moncure <mmoncure@gmail.com>
To: "Ronald Hahn, DOCFOCUS INC." <rhahn@docfocus.ca>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201205/34
X-Sequence-Number: 46858

On Thu, May 3, 2012 at 10:28 AM, Ronald Hahn, DOCFOCUS INC.
<rhahn@docfocus.ca> wrote:
> After some testing using wiershark (poor mans profiler) to see what was
> going on with the network I found that it was the tools I've been using.
> Both Aqua and PGadminIII have a large overhead per column to get the meta
> data. MSSQL sends that data upfront so the impact isn't as bad. I'm not sure
> if it's a limitation of the pgsql protocol vs tds or a limitation of Aqua or
> a combination of both. At any rate it turns out not to be part of the
> problem I'm having with my software stalling out so I'm back to Square one
> with my problem.

ok, let's figure out what the issue is then.  first, let's make sure
it isn't the server that's stalling: configure
log_min_duration_statement with an appropriate value so you start
catching queries that are taking longer then you think the should be.
 also some client side logging directly wrapping the SQL invocation
couldn't hurt.   is your application jdbc?

merlin



From shortcutter@googlemail.com Mon May  7 12:04:06 2012
Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 162481DB6346
	for <pgsql-performance@postgresql.org>;
	Mon,  7 May 2012 09:04:06 -0300 (ADT)
Received: from mail-yx0-f174.google.com ([209.85.213.174])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <shortcutter@googlemail.com>) id 1SRMfX-0007Vi-RN
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 12:04:06 +0000
Received: by yenm10 with SMTP id m10so3543226yen.19
	for <pgsql-performance@postgresql.org>;
	Mon, 07 May 2012 05:03:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=aoJqsVt9BIICTwC1gvmaN1RGtR1mrpi4074VSiVCKbc=;
	b=NCaBlMitqbk7yzyMvDxoPYh05EGMXbo3likMhx2QgazgDMXzB62cBB1SOuZt5SZ2K/
	l29HrFGXs92cOvFNmCYMu2w/pRL5EyZuQ7kX1s+qa93jEbhbuMvxVnVaz1R1MAXvekWB
	fJkIGP5QL9u2scvFEVMbBYbujTthu9YzUYa04uIqO/X6rpTo511MaXns1R+bxA7V/DqN
	fKi5zsdWmqJzWqLWHVPaGNtTK87PqELcvam0JW7cWG4KpR6riBHRrflG6ZBBRHx3Heyz
	PzLYSVSEgyHQJdM/wltOZFazraMnI+cyttOEO/PjiJ4iMLoDi0iK5ZyJQNNDkzTYKHNJ
	zrKQ==
MIME-Version: 1.0
Received: by 10.50.169.3 with SMTP id aa3mr1914340igc.28.1336392226227; Mon,
	07 May 2012 05:03:46 -0700 (PDT)
Received: by 10.64.16.40 with HTTP; Mon, 7 May 2012 05:03:46 -0700 (PDT)
In-Reply-To: 
 <CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
	<CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
Date: Mon, 7 May 2012 14:03:46 +0200
Message-ID: 
 <CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Robert Klemme <shortcutter@googlemail.com>
To: pgsql-performance <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Pg-Spam-Score: -2.7 (--)
X-Archive-Number: 201205/57
X-Sequence-Number: 46881

On Thu, May 3, 2012 at 5:40 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, May 3, 2012 at 10:28 AM, Ronald Hahn, DOCFOCUS INC.
> <rhahn@docfocus.ca> wrote:
>> After some testing using wiershark (poor mans profiler) to see what was
>> going on with the network I found that it was the tools I've been using.
>> Both Aqua and PGadminIII have a large overhead per column to get the met=
a
>> data. MSSQL sends that data upfront so the impact isn't as bad. I'm not =
sure
>> if it's a limitation of the pgsql protocol vs tds or a limitation of Aqu=
a or
>> a combination of both. At any rate it turns out not to be part of the
>> problem I'm having with my software stalling out so I'm back to Square o=
ne
>> with my problem.

So, Ronald, are you saying the different approach to meta data
transfer is _not_ the issue?

> ok, let's figure out what the issue is then. =A0first, let's make sure
> it isn't the server that's stalling: configure
> log_min_duration_statement with an appropriate value so you start
> catching queries that are taking longer then you think the should be.
> =A0also some client side logging directly wrapping the SQL invocation
> couldn't hurt. =A0 is your application jdbc?

Ronald said ODBC in his first posting.  But since ADS seems to support
JDBC as well trying that might be a good test to get another data
point.  Alternative tools for JDBC tests:

http://squirrel-sql.sourceforge.net/
http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/in=
dex.html

Using the PG client remotely with "\timing on" might be an even better idea=
.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/



From spam_eater@gmx.net Mon May  7 12:10:41 2012
Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 64F3E1DB6347
	for <pgsql-performance@postgresql.org>;
	Mon,  7 May 2012 09:10:41 -0300 (ADT)
Received: from plane.gmane.org ([80.91.229.3])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <gcdpp-pgsql-performance@m.gmane.org>)
	id 1SRMm0-0007mk-G2
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 12:10:41 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcdpp-pgsql-performance@m.gmane.org>)
	id 1SRMll-00069o-Mt
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 14:10:25 +0200
Received: from 217.110.94.67 ([217.110.94.67])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <pgsql-performance@postgresql.org>; Mon, 07 May 2012 14:10:25 +0200
Received: from spam_eater by 217.110.94.67 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <pgsql-performance@postgresql.org>; Mon, 07 May 2012 14:10:25 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: pgsql-performance@postgresql.org
From: Thomas Kellerer <spam_eater@gmx.net>
Subject: Re: Result Set over Network Question
Date: Mon, 07 May 2012 14:11:53 +0200
Lines: 17
Message-ID: <jo8e37$lkf$1@dough.gmane.org>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
	<CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
	<CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 217.110.94.67
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
In-Reply-To: 
 <CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
X-Pg-Spam-Score: -0.7 (/)
X-Archive-Number: 201205/58
X-Sequence-Number: 46882

Robert Klemme, 07.05.2012 14:03:
> Alternative tools for JDBC tests:
>
> http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html

SQL Developer does not support PostgreSQL

This page:

     http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools

also lists several JDBC based tools.

Thomas







From shortcutter@googlemail.com Mon May  7 13:44:54 2012
Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id ED3921DB6346
	for <pgsql-performance@postgresql.org>;
	Mon,  7 May 2012 10:44:54 -0300 (ADT)
Received: from mail-yx0-f174.google.com ([209.85.213.174])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <shortcutter@googlemail.com>) id 1SROF8-0001up-1Y
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 13:44:53 +0000
Received: by yenm10 with SMTP id m10so3632705yen.19
	for <pgsql-performance@postgresql.org>;
	Mon, 07 May 2012 06:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=JWzJ6IDSzB0gIgfGrbrOB+6OAJjRrhAVnA23GuVPwaM=;
	b=iHJHLX6PcEaiCD9Mt0bm7wlMFjAXbD9nsRwfbP2NIeP1BRSuOBWhdrxQJHntAAO/gM
	7npTRZ8W7r5CmdLwrFBuNOPFPvsX1p+EU2sdhhbS/yc6Sc8ewcEm6sjHHyC8eMm3+VUB
	1J45TkhUGEqUNqSLLZlbJKR0GIxBBDqIQOEXRmDYhMxk/Dq+XwpXKfw9UaQv7qKqMlLn
	r+FRzrPAAFjxwhbZbupYLJnmMjm7LaD0H6HVgn9H+6OLJljh6s92T0QDANAeAl0uqpjM
	yIqehcRq5KR4uIwhjkOIXQjtyX4pxUoaC3UY2VRU3dON0/naY3vezVEofnKSuSZfriCZ
	7Dhg==
MIME-Version: 1.0
Received: by 10.50.156.229 with SMTP id wh5mr8355652igb.28.1336398276859; Mon,
	07 May 2012 06:44:36 -0700 (PDT)
Received: by 10.64.16.40 with HTTP; Mon, 7 May 2012 06:44:36 -0700 (PDT)
In-Reply-To: <jo8e37$lkf$1@dough.gmane.org>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
	<CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
	<CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
	<jo8e37$lkf$1@dough.gmane.org>
Date: Mon, 7 May 2012 15:44:36 +0200
Message-ID: 
 <CAM9pMnPKNs7s=ZCaKS48m_EPf4s66A_x8K3X7zJHPnPHoeq-kQ@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Robert Klemme <shortcutter@googlemail.com>
To: Thomas Kellerer <spam_eater@gmx.net>,
	pgsql-performance <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Pg-Spam-Score: -2.7 (--)
X-Archive-Number: 201205/59
X-Sequence-Number: 46883

On Mon, May 7, 2012 at 2:11 PM, Thomas Kellerer <spam_eater@gmx.net> wrote:
> Robert Klemme, 07.05.2012 14:03:
>>
>> Alternative tools for JDBC tests:
>>
>> http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html
>
> SQL Developer does not support PostgreSQL

Last time I checked (quite a while ago) you could use arbitrary JDBC
drivers.  There's also
http://docs.oracle.com/cd/E25259_01/appdev.31/e24285/intro.htm#sthref306

And this seems to indicate that it's still the case: "[...] or another
third-party driver. [...]
JDBC URL (Other Third Party Driver): URL for connecting directly from
Java to the database; overrides any other connection type
specification."
http://docs.oracle.com/cd/E25259_01/appdev.31/e24285/dialogs.htm#BACDGCIA

I assume Oracle is not interested in aggressively advertizing this
feature though.

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/



From spam_eater@gmx.net Mon May  7 14:24:38 2012
Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id B1CC51DB6346
	for <pgsql-performance@postgresql.org>;
	Mon,  7 May 2012 11:24:38 -0300 (ADT)
Received: from plane.gmane.org ([80.91.229.3])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <gcdpp-pgsql-performance@m.gmane.org>)
	id 1SROrc-0000Zb-T3
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 14:24:37 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcdpp-pgsql-performance@m.gmane.org>)
	id 1SROrM-0007ha-3G
	for pgsql-performance@postgresql.org; Mon, 07 May 2012 16:24:20 +0200
Received: from 217.110.94.67 ([217.110.94.67])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <pgsql-performance@postgresql.org>; Mon, 07 May 2012 16:24:20 +0200
Received: from spam_eater by 217.110.94.67 with local (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <pgsql-performance@postgresql.org>; Mon, 07 May 2012 16:24:20 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: pgsql-performance@postgresql.org
From: Thomas Kellerer <spam_eater@gmx.net>
Subject: Re: Result Set over Network Question
Date: Mon, 07 May 2012 16:25:44 +0200
Lines: 35
Message-ID: <jo8lu7$oge$1@dough.gmane.org>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
	<CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
	<CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
	<jo8e37$lkf$1@dough.gmane.org>
	<CAM9pMnPKNs7s=ZCaKS48m_EPf4s66A_x8K3X7zJHPnPHoeq-kQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 217.110.94.67
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
In-Reply-To: 
 <CAM9pMnPKNs7s=ZCaKS48m_EPf4s66A_x8K3X7zJHPnPHoeq-kQ@mail.gmail.com>
X-Pg-Spam-Score: -0.7 (/)
X-Archive-Number: 201205/60
X-Sequence-Number: 46884

Robert Klemme, 07.05.2012 15:44:
>>> http://www.oracle.com/technetwork/developer-tools/sql-developer/overview/index.html
>>
>> SQL Developer does not support PostgreSQL
>
> Last time I checked (quite a while ago) you could use arbitrary JDBC
> drivers.  There's also
> http://docs.oracle.com/cd/E25259_01/appdev.31/e24285/intro.htm#sthref306
>
> And this seems to indicate that it's still the case: "[...] or another
> third-party driver. [...]
> JDBC URL (Other Third Party Driver): URL for connecting directly from
> Java to the database; overrides any other connection type
> specification."
> http://docs.oracle.com/cd/E25259_01/appdev.31/e24285/dialogs.htm#BACDGCIA
>
> I assume Oracle is not interested in aggressively advertizing this
> feature though.

That seems to be a documentation bug.
I tried it, and it definitely does not work (or I am missing something).

Their release notes at: http://www.oracle.com/technetwork/developer-tools/sql-developer/sqldev31-ea-relnotes-487612.html


state:

Third Party Databases

     SQL Developer supports IBM DB2 UDB LUW , Microsoft SQL Server and Microsoft Access, MySQL, Sybase Adaptive Server and Teradata.
     See Supported Platforms for details on all third party database releases supported.


Regards
Thomas




From shortcutter@googlemail.com Tue May  8 09:55:14 2012
Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 91CA098FC83
	for <pgsql-performance@postgresql.org>;
	Tue,  8 May 2012 06:55:14 -0300 (ADT)
Received: from mail-yw0-f46.google.com ([209.85.213.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <shortcutter@googlemail.com>) id 1SRh8S-000350-SR
	for pgsql-performance@postgresql.org; Tue, 08 May 2012 09:55:14 +0000
Received: by yhmm54 with SMTP id m54so5109401yhm.19
	for <pgsql-performance@postgresql.org>;
	Tue, 08 May 2012 02:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=QZ0849+GIZVHxLDTnwE6+b9Z1woMKS7sJw6lE+L3idk=;
	b=C1R/jeEx5K1FeJrhvetj/saGVN3wAuDI0U/ViXCGCTy3Aq1tmPLM1QKHBz7pQnfYNq
	9NCyGC8ye3piJzJEfbJhgAfZmuHRk2XxdecrTDSm3NxSXnHXzcfyU9rOBBEA3ZJsv2IS
	nNvnadfzR3QrY8XEQDxnKewbvHySemVWDUAEG14TGbjzx1q72xanvHLI63VE7Rtcg1BL
	I3xWPf9ZbPQFijyygbTqtHP0cm/1fnO64rxysx1RxSegM8RE0CHTboK64rb9wvJAuVW4
	BXZPQ5zsM2yag7L3od4VsGvaa18KHyzggDqUA2lfzqB6CqCqiBOvkvlU3fJ6nqh08wTo
	9S8Q==
MIME-Version: 1.0
Received: by 10.50.173.69 with SMTP id bi5mr5604201igc.38.1336470899909; Tue,
	08 May 2012 02:54:59 -0700 (PDT)
Received: by 10.64.16.40 with HTTP; Tue, 8 May 2012 02:54:59 -0700 (PDT)
In-Reply-To: <jo8lu7$oge$1@dough.gmane.org>
References: <4F9EDACA.4010901@docfocus.ca>
	<CAHyXU0wdmbGNQgqwBVZR5UY6Nmb3-L6LSi+XA+gjMtqMFn-3Ww@mail.gmail.com>
	<4FA2A42C.9090900@docfocus.ca>
	<CAHyXU0xFBy7m=3jUc=JtBBCUCBkKPuFsj48a1z=5zM+tb1HWoQ@mail.gmail.com>
	<CAM9pMnOx8GcrU7eV2HZAJ3FyKr_h4tpXJBWsuj7JUdw9W1eQdw@mail.gmail.com>
	<jo8e37$lkf$1@dough.gmane.org>
	<CAM9pMnPKNs7s=ZCaKS48m_EPf4s66A_x8K3X7zJHPnPHoeq-kQ@mail.gmail.com>
	<jo8lu7$oge$1@dough.gmane.org>
Date: Tue, 8 May 2012 11:54:59 +0200
Message-ID: 
 <CAM9pMnMDeRLvUsqV52ktsqBARr8Ov=ZgLpAK2S9v5Gioc4J_0Q@mail.gmail.com>
Subject: Re: Result Set over Network Question
From: Robert Klemme <shortcutter@googlemail.com>
To: pgsql-performance <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201205/61
X-Sequence-Number: 46885

On Mon, May 7, 2012 at 4:25 PM, Thomas Kellerer <spam_eater@gmx.net> wrote:
> That seems to be a documentation bug.
> I tried it, and it definitely does not work (or I am missing something).

Apparently I am the one who is missing something. :-)

> Their release notes at:
> http://www.oracle.com/technetwork/developer-tools/sql-developer/sqldev31-=
ea-relnotes-487612.html
>
> state:
>
> Third Party Databases
>
> =A0 =A0SQL Developer supports IBM DB2 UDB LUW , Microsoft SQL Server and
> Microsoft Access, MySQL, Sybase Adaptive Server and Teradata.
> =A0 =A0See Supported Platforms for details on all third party database re=
leases
> supported.

Right you are, Thomas!  Thank you!  Sorry for the confusion.

Kind regards

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/