Tom Lane wrote:
In case I was mistaken, this explanation makes perfectly sens to me.
But then again it would indicate a 'bug' in libpq, in the sense that
it (apparently) sets TCP_NODELAY on linux but not on windows.
No, it would mean a bug in Windows in that it fails to honor TCP_NODELAY.
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> On 12/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> I think this almost certainly indicates a Nagle/delayed-ACK
>> interaction. I googled and found a nice description of the issue:
>> http://www.stuartcheshire.org/papers/NagleDelayedAck/
> In cas
On 12/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> I tested different sizes on linux some time ago and found that 64KB
> was optimal. But playing with different sizes again revealed that my
> windows->linux problem seems to be solved if I use _any_
* Tom Lane:
> If you don't like that theory, another line of reasoning has to do with
> the fact that the maximum advertiseable window size in TCP is 65535 ---
> there could be some edge-case behaviors in the Windows and Linux stacks
> that don't play nicely together for 64K transfer sizes.
Linux
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> I tested different sizes on linux some time ago and found that 64KB
> was optimal. But playing with different sizes again revealed that my
> windows->linux problem seems to be solved if I use _any_ other
> (reasonable - meaning something between 4K
On 12/11/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Yeah, that's what I couldn't think of the other day. The principal
report was here:
http://archives.postgresql.org/pgsql-general/2005-01/msg01231.php
By default, Windows XP installs the QoS Packet Scheduler service.
It is not installed by
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> On 12/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
>> This has to be a network-level problem. IIRC, there are some threads in
>> our archives discussing possibly-related performance issues seen with
>> Windows' TCP stack.
> I searched the archives b
On 12/11/06, Thomas H. <[EMAIL PROTECTED]> wrote:
> I'm out of ideas here, maybe someone could try to reproduce this
> behavior or could point me to the thread containing relevant
> information (sorry, maybe I'm just too dumb :-/)
please specify how you're transfering the data from windows -> li
I'm out of ideas here, maybe someone could try to reproduce this
behavior or could point me to the thread containing relevant
information (sorry, maybe I'm just too dumb :-/)
please specify how you're transfering the data from windows -> linux. are
you using odbc? if yes, what driver? are you u
On 12/9/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> ... This works quite well for the
> following setups:
> client -> server
> -
> linux -> linux
> linux -> windows
> windows -> windows
> but pretty bad (meaning about 10 times
"Axel Waggershauser" <[EMAIL PROTECTED]> writes:
> ... This works quite well for the
> following setups:
> client -> server
> -
> linux -> linux
> linux -> windows
> windows -> windows
> but pretty bad (meaning about 10 times slower) for this setup
> windows -> linux
This h
Hi,
I have written my own 'large object'-like feature using the following table:
CREATE TABLE blob
(
id bigint NOT NULL,
pageno integer NOT NULL,
data bytea,
CONSTRAINT blob_pkey PRIMARY KEY (id, pageno)
)
WITHOUT OIDS;
ALTER TABLE blob ALTER COLUMN data SET STORAGE EXTERNAL;
CREATE SEQUEN
12 matches
Mail list logo