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_ other
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 case I was
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
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 slower) for this
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
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 - linux.
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 but found
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:
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 and
* 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
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
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 has to be a
12 matches
Mail list logo
