Ross J. Reedstrom escribió:
Excellent. I'll take a look at this and report back here.
Ross
On Mon, Feb 23, 2009 at 04:17:00PM -0500, Tom Lane wrote:
"Ross J. Reedstrom" <reeds...@rice.edu> writes:
Summary: C client and large-object API python both send bits in
reasonable time, but I suspect there's still room for improvement in
libpq over TCP: I'm suspicious of the 6x difference. Detailed analysis
will probably find it's all down to memory allocation and extra copying
of bits around (client side)
I wonder if the backend isn't contributing to the problem too. It chops
its sends up into 8K units, which doesn't seem to create huge overhead
in my environment but maybe it does in yours. It'd be interesting to see
what results you get from the attached quick-and-dirty patch (against
HEAD, but it should apply back to at least 8.1).
regards, tom lane
Hello, i have been having a problem like this in debian machines and i have
discovered that (almost in my case), the problem only arises when i am using
"ssl = true" in postgresql.conf although i am using clear tcp connections to
localhost to perform my query, if i disable ssl in configuration my localhost
query times goes from 4200ms to 110ms, the same parameter does not have this
effect in my Arch Linux development machine, so maybe you should see how this
parameter affect your setup Ross. My original post to general list is in
http://archives.postgresql.org/pgsql-general/2009-02/msg01297.php for more
information.
Regards,
Miguel Angel.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
