Re: Prepared statements performance
От | Tom Lane |
---|---|
Тема | Re: Prepared statements performance |
Дата | |
Msg-id | 29805.1336660941@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Prepared statements performance (Alban Hertroys <haramrae@gmail.com>) |
Ответы |
Re: Prepared statements performance
|
Список | pgsql-general |
Alban Hertroys <haramrae@gmail.com> writes: > On 10 May 2012 15:05, Radosław Smogura <rsmogura@softperience.eu> wrote: >> May I ask what kind of planning may occur during insert? > Well, for example, if there's a unique constraint on the table then > the database will have to check that the newly inserted values don't > conflict with values that are already in the table. It needs to plan > an efficient strategy for that, which depends on the values being > inserted. There is no planning associated with checking unique constraints; that's just a matter for the index mechanisms. I think the real point here is that a simple INSERT/VALUES has such a trivial plan that there is hardly any gain to be had by avoiding the planning stage. Then the other overhead of a prepared statement (looking up the saved plan, checking it's not stale, etc) outweighs that. Or at least it could. 3x slower seems a bit fishy; I wonder whether there's some client-side inefficiency involved in that. Doing performance measurements with pgAdmin seems pretty questionable in the first place ... regards, tom lane
В списке pgsql-general по дате отправления: