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

From Tom Lane
Subject Re: [HACKERS] Postgres Speed or lack thereof
Date
Msg-id 471.916678052@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Postgres Speed or lack thereof  (Hannu Krosing <hannu@trust.ee>)
List pgsql-hackers
Hannu Krosing <hannu@trust.ee> writes:
> I am sure that we need to change the protocol sometime soon, if we 
> want to increase the performance.

The immediate problem is just that we've given back performance that we
had a week ago.  stdio-based libpq didn't have this problem, because it
dealt with the kernel a bufferload at a time not a character at a time.

Also, while the fe/be protocol is certainly a bit crufty, I'm not
convinced that a well-designed frontend is going to suffer any real
performance problem from parsing the protocol.  The trick again is to
read into a buffer and parse from the buffer.  The last time I profiled
frontend libpq, it turned out to be spending all its time in memory
allocation not parsing.  (Which I fixed, btw.)

> And of course we need some sort of CLI that can do prepared statements 
> and that can use binary fields (not only the file interface).

> Currently we have some of it, bu only in SPI.

SPI?  I missed something ... what's that?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Syntax errors in current tree
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Postgres Speed or lack thereof