RE: [HACKERS] Postgres Speed or lack thereof

> 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