Hi,
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 14:43:57 -0400
What I would think might help is a patch on the libpq side (because it
*does* use a nonblocking socket) to avoid sending more than
8K per WSASend call
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
I think libpq interface does not use non-blocking socket.
Not unless the Windows port has also disabled pg_set_noblock ...
regards, tom lane
---(end of broadcast)---
TIP 3: Have
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Wed, 28 Jun 2006 09:54:21 -0400
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
I think libpq interface does not use non-blocking socket.
Not unless the Windows port has also disabled pg_set_noblock
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
pqcomm.c:117
#define PQ_BUFFER_SIZE 8192
send() may take as long as 200ms. So,
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
send() may take as long as 200ms. So, I think we should increase
SO_SNDBUF to more than 8192. I attache the patch.
Why would that help? We won't be sending more than 8K at a time.
regards, tom lane
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
Ok, so
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 11:30:56 -0400
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
send() may take as long as 200ms. So, I think we should increase
SO_SNDBUF to more than 8192. I attache the patch.
Why
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Martijn van Oosterhout
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
On Tue, Jun 27, 2006 at 11:45:53AM -0400, Andrew Dunstan wrote:
No, it says it occurs if this condition is met: A single *send* call or
*WSASend* call fills the whole underlying socket send buffer.
This will surely be true if the buffer sizes are the same. They
recommend making the socket
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
http://support.microsoft.com/kb/823764/EN-US/
No, it says it occurs if this condition is met: A single *send* call or
*WSASend* call fills the whole
From: Martijn van Oosterhout kleptog@svana.org
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 18:13:18 +0200
On Tue, Jun 27, 2006 at 11:45:53AM -0400, Andrew Dunstan wrote:
No, it says it occurs if this condition is met: A single *send* call or
*WSASend
From: Tom Lane [EMAIL PROTECTED]
Subject: Re: [HACKERS] SO_SNDBUF size is small on win32?
Date: Tue, 27 Jun 2006 12:28:35 -0400
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:23:13AM +0900, Yoshiyuki Asaba wrote:
http
Yoshiyuki Asaba [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
It also says that the condition only occurs if the program uses
non-blocking sockets ... which the backend does not. So this page
offers no support for the proposed patch.
WSAEventSelect() sets a socket to
From: Tom Lane [EMAIL PROTECTED]
It also says that the condition only occurs if the program uses
non-blocking sockets ... which the backend does not. So this page
offers no support for the proposed patch.
WSAEventSelect() sets a socket to nonblocking mode.
Yeah, but that socket
I would set the SO_SNDBUF to 32768.
Hi,
I see a performance issue on win32. This problem is causes by the
following URL.
http://support.microsoft.com/kb/823764/EN-US/
On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
8192 too.
pqcomm.c:117
#define
Magnus Hagander [EMAIL PROTECTED] writes:
We use non-blocking sockets in backend/port/win32/socket.c so we are
able to deliver our faked signals while waiting for I/O on the socket.
We specifically set it in pgwin32_socket().
Hm, that seems a bit grotty, but anyway I stand corrected.
Given
We have definitly seen weird timing issues sometimes when both client
and server were on Windows, but have been unable to pin it exactly on
what. From Yoshiykis other mail it looks like this could possibly be it,
since he did experience a speedup in the range we've been looking for in
those
18 matches
Mail list logo