Re: TCP network cost

From: Linos
Subject: Re: TCP network cost
Date: ,
Msg-id: 49AAC6AC.60309@linos.es
(view: Whole thread, Raw)
In response to: Re: TCP network cost  ("Ross J. Reedstrom")
Responses: Re: TCP network cost  (Tom Lane)
List: pgsql-performance

Tree view

TCP network cost  ("Ross J. Reedstrom", )
 Re: TCP network cost  (Rusty Conover, )
  Re: TCP network cost  (, )
  Re: TCP network cost  ("Ross J. Reedstrom", )
   Re: TCP network cost  (Rusty Conover, )
    Re: TCP network cost  ("Ross J. Reedstrom", )
     Re: TCP network cost  ("Ross J. Reedstrom", )
      Re: TCP network cost  (Aaron Turner, )
     Re: TCP network cost  (PFC, )
      Re: TCP network cost  ("Ross J. Reedstrom", )
   Re: TCP network cost  (Gregory Stark, )
    Re: TCP network cost  ("Ross J. Reedstrom", )
     Re: TCP network cost  (Tom Lane, )
      Re: TCP network cost  ("Ross J. Reedstrom", )
       Re: TCP network cost  (Linos, )
        Re: TCP network cost  (Tom Lane, )
         Re: TCP network cost  (Linos, )
          Re: TCP network cost  (Tom Lane, )
           Re: TCP network cost  (Linos, )
            Re: TCP network cost  (Tom Lane, )
             Re: TCP network cost  (Magnus Hagander, )
              Re: TCP network cost  (Linos, )
 Re: TCP network cost  (Aaron Turner, )

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" <> 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.


pgsql-performance by date:

From: "Cox, Brian"
Date:
Subject: Re: "slow" queries
From: Tom Lane
Date:
Subject: Re: "slow" queries