On 09/07/10 22:08, Tom Lane wrote: > Andras Fabian <Fabian@xxxxxxxxxx> writes: >>> Something weird about the network stack on the new machine, maybe. >>> Have you compared the transfer speeds for Unix-socket and TCP connections? > >> Hmm, no ... but how do Unix-socket / TCP connections relate to STDOUT here (sorry, maybe this is obvious to some, but not to me at the moment)? > > Well, COPY TO STDOUT really means "send the data across the network > connection to the client". It sounds to me like your problem is slow > data transfer between the database backend and pg_dump (or psql). > Not sure what could be causing it, unless perhaps you've got a kernel > packet filter that's performing an unreasonable amount of processing > per packet. ... and that should be showing up as high "system" CPU time, or it seems to on my machines with lots of tcp/ip traffic and heavy netfilter rules. If they're using unix sockets packet filtering shouldn't come into play anyway. Andrais: Are you using UNIX sockets or TCP/IP to connect to PostgreSQL? If you specify any host to connect to, even "localhost", you're using TCP/IP. If you don't specify a host, you're using unix sockets. Whichever you are doing, try the other one and see if performance is different. Idea: One notable difference between COPY to file and 'copy to stdout" to a receiving process over the network is that the latter involves the interaction of two processes. When a kernel change is involved and you're seeing low performance with lots of apparent idleness, that immediately makes me think "process scheduler". Of course, that might be completely off-track, but I've seen weird performance issues caused by scheduler changes before. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
