On 11/09/10 11:22 PM, Alban Hertroys wrote:
Do both machines have similar hardware? If the Linux machine has a
proper NIC (intel, for example) while the Windows machine has a poor
NIC (Realtek!), then of course you would get differences in performance.
I'm not saying Microsofts network stack is
Op 10-11-10 08:22, Alban Hertroys schreef:
On 10 Nov 2010, at 5:19, Rob Brown-Bayliss wrote:
Further testing shows it is windows networking causing the issue.
Copying files to and from the server is 5 to 6 times slower on a
Windows client compared to the Linux client.
The issue is not specific
On 10 Nov 2010, at 5:19, Rob Brown-Bayliss wrote:
> Further testing shows it is windows networking causing the issue.
> Copying files to and from the server is 5 to 6 times slower on a
> Windows client compared to the Linux client.
>
> The issue is not specific to libpq.
Do both machines have si
On 11/09/10 9:53 PM, Dann Corbit wrote:
Check your Nagle setting.
http://support.microsoft.com/kb/138831
that link works for SNA Server, which is some real obscure stuff, but
not the general case
try this, http://www.speedguide.net/articles/windows-2kxp-more-tweaks-158
where it says _Gaming
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of Rob Brown-Bayliss
> Sent: Tuesday, November 09, 2010 8:20 PM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Libpq is very slow on w
Further testing shows it is windows networking causing the issue.
Copying files to and from the server is 5 to 6 times slower on a
Windows client compared to the Linux client.
The issue is not specific to libpq.
--
Rob
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To mak
Hi
No Joy. The tcp window stuff didn't make any difference. I tried
the unscientific speedtest.net to a server in Canada and all 3
machines (several times each)(. Linux, XP and Vista. The results are
all too close to call.
Yet psql or pgadmin are 4 or 5 times slower on the windows machines.
On 07/11/10 09:13, Rob Brown-Bayliss wrote:
> Ok, So I did that, in the windows capture file are many many lines of
> Red text on a black background, I assume thats a bad thing.
If you examine the packet it'll say "invalid checksum". This will be
because your network card is doing TCP checksum off
Thanks, I will a look at that latter, but I am not too hopeful as I
get the same results on Vista as XP. One thought that has occurred
to me is could it be libpq.dll versions? I am not able to test until
later on today, but the server is postgresql 8.3 and the XP machine
is using libpq frim the
On 11/06/10 6:27 PM, Rob Brown-Bayliss wrote:
On Sun, Nov 7, 2010 at 1:06 PM, John R Pierce wrote:
how about if you do something like, SELECT * FROM SOME_TABLE INTO
SOME_OTHER_TABLE; which doesn't involve returning data?
In this case the times are as close to equal as to make no difference,
On 11/06/10 6:13 PM, Rob Brown-Bayliss wrote:
Ok, So I did that, in the windows capture file are many many lines of
Red text on a black background, I assume thats a bad thing. It's
every second or third line vs just a handful on the linux capture.
Most of these lines are like:
postgresql [ACK]
On Sun, Nov 7, 2010 at 1:06 PM, John R Pierce wrote:
> how about if you do something like, SELECT * FROM SOME_TABLE INTO
> SOME_OTHER_TABLE; which doesn't involve returning data?
In this case the times are as close to equal as to make no difference,
within a couple of ms of each other. About 3
Ok, So I did that, in the windows capture file are many many lines of
Red text on a black background, I assume thats a bad thing. It's
every second or third line vs just a handful on the linux capture.
Most of these lines are like:
postgresql [ACK] Seq=5429 Ack=# Win=65700 Len=0
Where the
On 11/06/10 5:12 PM, Rob Brown-Bayliss wrote:
On Sun, Nov 7, 2010 at 1:06 PM, John R Pierce wrote:
I think I'd run a packet sniffer like Wireshark on both client platforms,
sniffing 5432/tcp and see if there's something unusual in the timing of the
packets, incorrect MTU or something, lost pack
On Sun, Nov 7, 2010 at 1:06 PM, John R Pierce wrote:
> when you say 500mS, thats the round trip ping time?
It's a bit less, for example SELECT max(id) on the same table takes
about 350ms. Yes, I am in New Zealand, the server is in Canada. pings
take about 275ms average.
> I think I'd run a pack
Thanks, but no, it's using ip, and after the connection has been
established etc. the 3500ms it the total query time on windows vs
800ms on linux. Same server, so I think it is related to libpq
implementation on windows.
I also get the same results running XP in a virtualbox on a linux
machine, w
On 11/06/10 4:54 PM, Rob Brown-Bayliss wrote:
Hi
I have a problem with libpq on windows. Connecting to a db and running
a "select * from some_table;" is very slow.
The table has only 1800 rows, 7 columns. No blobs etc.
The query is taking around 3500ms, in linux it takes around 800ms.
(About 5
On 11/06/2010 04:54 PM, Rob Brown-Bayliss wrote:
> Hi
>
> I have a problem with libpq on windows. Connecting to a db and running
> a "select * from some_table;" is very slow.
>
> The table has only 1800 rows, 7 columns. No blobs etc.
>
> The query is taking around 3500ms, in linux it takes aroun
Hi
I have a problem with libpq on windows. Connecting to a db and running
a "select * from some_table;" is very slow.
The table has only 1800 rows, 7 columns. No blobs etc.
The query is taking around 3500ms, in linux it takes around 800ms.
(About 500ms is network time, the server is on the oppos
19 matches
Mail list logo
