Re: performance of first exec of prepared statement

From: Ted Toth <txtoth(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: performance of first exec of prepared statement
Date: 2020-04-17 13:34:12
Message-ID: CAFPpqQHSjgVFKjHEOtzd+K5k120GVeaEed644c=M3nvyHBBjLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Apr 17, 2020 at 8:28 AM Ted Toth <txtoth(at)gmail(dot)com> wrote:

>
>
> On Thu, Apr 16, 2020 at 8:09 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:
>
>> 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(at)gmail(dot)com
>> >> <mailto:txtoth(at)gmail(dot)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).
>>
>>
>>
>> I thought that's what the PQprepare call was supposed to do i.e.
> parsing/planning.
>
> It's a bit difficult to get an unprepared query cost since there are a lot
> of columns :(
> #define INSERT_SQL "INSERT INTO t (<column names>) VALUES
> ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$60,$61,$62,$63,$64,$65,$66,$67,$68,$69,$70,$71,$72,$73,$74,$75,$76,$77,$78,$79,$80,$81,$82,$83,$84,$85,$86,$87);"
>
> Ah prepare does the parsing and execute does the planning.

Another related question is that my implementation uses strings for all
values is there a performance benefit to using actual values and specifying
their datatype?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rob Sargent 2020-04-17 13:48:59 Re: performance of first exec of prepared statement
Previous Message Sonam Sharma 2020-04-17 13:31:21 Replication issue