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
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_ |