Skip site navigation (1) Skip section navigation (2)

Re: performance for high-volume log insertion

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: david(at)lang(dot)hm
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: performance for high-volume log insertion
Date: 2009-04-22 02:29:16
Message-ID: 603c8f070904211929o32dbe138ue7f1f1f32f2784c9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, Apr 21, 2009 at 8:12 PM,  <david(at)lang(dot)hm> wrote:
>> Using prepared queries, at least if you use PQexecPrepared or
>> PQexecParams, also reduces the work required on the client to build the
>> whole string, and the parsing overhead on the database side to pull it
>> apart again.  That's where the performance is going to be improved by
>> going that route, not so much in eliminating the planning.
>
> in a recent thread about prepared statements, where it was identified that
> since the planning took place at the time of the prepare you sometimes have
> worse plans than for non-prepared statements, a proposal was made to have a
> 'pre-parsed, but not pre-planned' version of a prepared statement. This was
> dismissed as a waste of time (IIRC by Tom L) as the parsing time was
> negligable.
>
> was that just because it was a more complex query to plan?

Joins are expensive to plan; a simple insert is not.  I also disagree
that pre-parsed but not pre-planned is a waste of time, whoever said
it.  Sometimes it's what you want, especially in PL/pgsql.

...Robert

In response to

pgsql-performance by date

Next:From: James MansionDate: 2009-04-22 05:26:07
Subject: Re: performance for high-volume log insertion
Previous:From: davidDate: 2009-04-22 00:12:26
Subject: Re: performance for high-volume log insertion

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group