RE: [HACKERS] Postgres Speed or lack thereof - Mailing list pgsql-hackers

From Magnus Hagander
Subject RE: [HACKERS] Postgres Speed or lack thereof
Date
Msg-id 215896B6B5E1CF11BC5600805FFEA821012A31C2@sirius.edu.sollentuna.se
Whole thread Raw
Responses Re: [HACKERS] Postgres Speed or lack thereof  (Bruce Momjian <maillist@candle.pha.pa.us>)
Re: [HACKERS] Postgres Speed or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The other thing that jumps out here is the unreasonably high 
> position of
> recv(), which is called 962187 times.  The script being read 
> by psql was
> only 957186 characters.  Evidently we're invoking a kernel recv() call
> once per character read from the frontend.  I suspect this is an
> inefficiency introduced by Magnus Hagander's recent rewrite of backend
> libpq (see, I told you there was a reason for using stdio ;-)).  We're
> gonna have to do something about that, though it's not as critical as
> the memory-allocation issue.  
Could be because of that. I noticed that the backend calls pq_getchar() a
_lot_ of times, looping for reading a single character. It did that before
too. The difference was that pq_getchar() called fgetc() then, and calls
recv() now.
I don't know, maybe recv() is more expensive than fgetc()? But I really
can't see any reason it shuold be called more often now than before.
An interesting fact is that pq_getchar() doesn't show up at all. Could be
because it's fast, but still executed many times, right? Or it could be that
the 'inner loops' in pq_getchar(), pq_peekchar(), or pqGetNBytes() don't
work as expected. On my system (Linux 2.2), I only get one recv() call for
each entry into these functions - as it should be - might it be different on
yours?

Ok, so I give up, perhaps we need a buffer after all :-)


//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: RE: [PATCHES] Another libpq-be patch
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] I need a PostgreSQL vacation