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 по дате отправления: