Re: Prepared statements performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alban Hertroys <haramrae(at)gmail(dot)com>
Cc: Radosław Smogura <rsmogura(at)softperience(dot)eu>, Daniel McGreal <daniel(dot)mcgreal(at)redbite(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Prepared statements performance
Date: 2012-05-10 14:42:21
Message-ID: 29805.1336660941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alban Hertroys <haramrae(at)gmail(dot)com> writes:
> On 10 May 2012 15:05, Radosaw Smogura <rsmogura(at)softperience(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Daniel McGreal 2012-05-10 14:50:18 Re: Prepared statements performance
Previous Message Alban Hertroys 2012-05-10 13:48:04 Re: Prepared statements performance