Re: embedded sql regression from 8.2.4 to 8.3.7

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: embedded sql regression from 8.2.4 to 8.3.7
Дата
Msg-id D960CB61B694CF459DCFB4B0128514C203937E29@exadv11.host.magwien.gv.at
обсуждение исходный текст
Ответ на Re: embedded sql regression from 8.2.4 to 8.3.7  ("Haszlakiewicz, Eric" <EHASZLA@transunion.com>)
Список 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 по дате отправления:

Предыдущее
От: Marc Cousin
Дата:
Сообщение: Re: Very big insert/join performance problem (bacula)
Следующее
От: Tim Uckun
Дата:
Сообщение: Re: [GENERAL] Postgres Clustering