Re: embedded sql regression from 8.2.4 to 8.3.7 - Mailing list pgsql-performance

From Albe Laurenz
Subject Re: embedded sql regression from 8.2.4 to 8.3.7
Date
Msg-id D960CB61B694CF459DCFB4B0128514C203937E29@exadv11.host.magwien.gv.at
Whole thread Raw
In response to Re: embedded sql regression from 8.2.4 to 8.3.7  ("Haszlakiewicz, Eric" <EHASZLA@transunion.com>)
List pgsql-performance
Eric Haszlakiewicz wrote:
>> The log is misleading; the first statement is not really executed,
>> it is only prepared (parsed). If you set the log level to DEBUG2, it
>> will look like:
>
> Yes, but it's still incurring the overhead of sending the message to the
> server, isn't it?

Yes.

>> Maybe it is the additional PREPARE that slows your program.
>> Are your queries complex enough that the PREPARE consumes
>> significant time?
>
> No, the queries aren't complex, but we prepare and excute hundred of
> queries, so it seems like the overhead of the extra message sent to the
> server adds up.

I see.

>  I was hoping there was a way to work around this by
> having Postgres not send that prepare to the server, but given the
> "major protocol rewrite" phrase on that commit log message you pointed
> me at, I'm guessing that's not possible.

It looks like what is normally an advantage (having named prepared
statements that can be reused) makes things slower in your case, since
you do not use the prepared statement at all and only need it to
be able to use a cursor with dynamic SQL.

Yours,
Laurenz Albe

pgsql-performance by date:

Previous
From: Marc Cousin
Date:
Subject: Re: Very big insert/join performance problem (bacula)
Next
From: Tim Uckun
Date:
Subject: Re: [GENERAL] Postgres Clustering