Re: embedded sql regression from 8.2.4 to 8.3.7

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Haszlakiewicz, Eric *EXTERN*" <EHASZLA(at)transunion(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: embedded sql regression from 8.2.4 to 8.3.7
Date: 2009-07-14 09:39:59
Message-ID: D960CB61B694CF459DCFB4B0128514C203937E29@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Lauris Ulmanis 2009-07-14 12:39:10 BUG #4919: CREATE USER command slows down system performance
Previous Message Marc Cousin 2009-07-14 09:22:16 Re: Very big insert/join performance problem (bacula)