Re: performance of first exec of prepared statement

Поиск
Список
Период
Сортировка
От Rob Sargent
Тема Re: performance of first exec of prepared statement
Дата
Msg-id b1dc3c29-5233-c2ac-887d-e2ef27fb64f8@gmail.com
обсуждение исходный текст
Ответ на Re: performance of first exec of prepared statement  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: performance of first exec of prepared statement
Список pgsql-general
On 4/16/20 6:15 PM, Adrian Klaver wrote:
> On 4/16/20 4:59 PM, Ted Toth wrote:
>>
>>
>> On Thu, Apr 16, 2020 at 6:29 PM Ted Toth <txtoth@gmail.com 
>> <mailto:txtoth@gmail.com>> wrote:
>>
>>     I've noticed that the first exec of an INSERT prepared statement
>>     takes ~5 time longer (I'm using libpq in C and wrapping the calls to
>>     time them) then subsequent exec's is this the expected behavior and
>>     if so is there any thing I can do to mitigate this affect?
>>
>>     Ted
>>
>>
>> For example (in my environment) I'm seeing the prepare take ~10ms, 
>> the first exec take ~30 ms and subsequent exec's take ~4 ms.
>>
>
> I don't have an answer. I believe though that to help those that might 
> it would be helpful to show the actual code.
>
>
You expect the subsequent calls to benefit from the cached query parse 
and planning.  What does you query cost without begin wrapped in a 
prepared statement (preferably from a cold start).




В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Could not resolve host name error in psycopg2
Следующее
От: derwin theduck
Дата:
Сообщение: Re: Could not resolve host name error in psycopg2