| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | L J Bayuk <ljb220(at)mindspring(dot)com> |
| Cc: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, pgsql-interfaces(at)postgresql(dot)org |
| Subject: | Re: pgin.tcl pg_exec_prepared slow (was: Released...) |
| Date: | 2004-07-07 01:27:45 |
| Message-ID: | 878ydwsj1q.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
L J Bayuk <ljb220(at)mindspring(dot)com> writes:
> The delay we are seeing (about 40 ms) is from the time the client sends the
> Bind message to PostgreSQL until it gets a TCP ACK back.
You might consider disabling the NAGLE algorithm. It can delay acks like this.
You could do this with setsockopt(SOL_TCP, TCP_NODELAY,...)
The problem is that while this would be perfectly appropriate for things like
bind messages, it's entirely inappropriate for the bulk data transfer
of the results of a query.
I would not suggest enabling TCP_NODELAY for all data. And I'm not sure how
implementations behave if you turn it on and off.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-07-07 01:44:17 | Re: pgin.tcl pg_exec_prepared slow (was: Released...) |
| Previous Message | Brijesh Shrivastav | 2004-07-06 23:50:49 | Libpq and transactions |