Re: Sending result sets from backend to frontend is _slow_

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: glenebob(at)nwlink(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Sending result sets from backend to frontend is _slow_
Date: 2000-11-07 01:59:14
Message-ID: 23299.973562354@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

pgsql-bugs(at)postgresql(dot)org writes:
> When operating over a fast network (ethernet), the sending of select
> result rows from the backend is very slow, ie. it uses only a small
> fraction of available network bandwidth. I am running postgres 7.0.2
> on a Redhat 6.1 install on x86, and using the postodbc driver on
> win2k, and I have looked at the odbc driver code until I am blue in
> the face :-) and I am confident that it is doing the right thing with
> network IO (large read buffers, 4096 bytes by default). There is also
> very low CPU utilization on both machines during large result
> transfers. From this, I believe the problem is in the backend, and I
> think it is probably sending one row per network write.

Certainly not! See the usage of pq_putbytes and pq_flush. The only
not-absolutely-necessary flush in the backend is just after sending
an error or notice message (which one would hope is a noncritical
path). I dunno what is causing your problem, but we're not quite that
dumb ;-)

Depending on what your test query is, it's possible that the server
machine is disk I/O bound --- have you checked?

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2000-11-07 07:33:58 Re: Sequence bug in insert trigger
Previous Message pgsql-bugs 2000-11-06 22:21:06 Sending result sets from backend to frontend is _slow_