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  (Daniel McGreal <daniel.mcgreal@redbite.com>)
Список 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 по дате отправления:

Предыдущее
От: Alban Hertroys
Дата:
Сообщение: Re: Prepared statements performance
Следующее
От: Daniel McGreal
Дата:
Сообщение: Re: Prepared statements performance