To: Rainer Bauer <usenet@munnin.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Data transfer very slow when connected via DSL 
In-reply-to: <24rl73d5td717rimunndjnjghfl1pgqojh@4ax.com> 
References: <s7tk73d57kvb3f4ph1kmkvhdfe0kak5a1r@4ax.com>
	<7be3f35d0706210801p732f2e73o147e3cbc0dc98153@mail.gmail.com>
	<d1el7392q4eab7uqud2ci3ihn2fqkusjms@4ax.com>
	<24rl73d5td717rimunndjnjghfl1pgqojh@4ax.com>
Comments: In-reply-to Rainer Bauer <usenet@munnin.com>
	message dated "Thu, 21 Jun 2007 23:26:43 +0200"
Date: Thu, 21 Jun 2007 21:51:11 -0400
Message-ID: <10461.1182477071@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Rainer Bauer <usenet@munnin.com> writes:
> Fetching the 50 rows takes 12 seconds (without logging 8 seconds) and
> examining the log I found what I suspected: the performance is directly
> related to the ping time to the server since fetching one tuple requires a
> round trip to the server.

Hm, but surely you can get it to fetch more than one row at once?

This previous post says that someone else solved an ODBC
performance problem with UseDeclareFetch=1:
http://archives.postgresql.org/pgsql-odbc/2006-08/msg00014.php

It's not immediately clear why pgAdmin would have the same issue,
though, because AFAIK it doesn't rely on ODBC.

I just finished looking through our archives for info about
Windows-specific network performance problems.  There are quite a few
threads, but the ones that were solved seem not to bear on your problem
(unless the one above does).  I found one pretty interesting thread
suggesting that the problem was buffer-size dependent:
http://archives.postgresql.org/pgsql-performance/2006-12/msg00269.php
but that tailed off with no clear resolution.  I think we're going to
have to get someone to watch the problem with a packet sniffer before
we can get much further.

			regards, tom lane