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

Re: performance for high-volume log insertion

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: david(at)lang(dot)hm
Cc: 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 12:19:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

* david(at)lang(dot)hm (david(at)lang(dot)hm) wrote:
> 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?

Yes, as I beleive was mentioned already, planning time for inserts is
really small.  Parsing time for inserts when there's little parsing that
has to happen also isn't all *that* expensive and the same goes for
conversions from textual representations of data to binary.

We're starting to re-hash things, in my view.  The low-hanging fruit is
doing multiple things in a single transaction, either by using COPY,
multi-value INSERTs, or just multiple INSERTs in a single transaction.
That's absolutely step one.

Adding in other things, where they make sense (prepared statements,
binary format for things you have as binary, etc) is a good idea if it
can be done along the way.


In response to


pgsql-performance by date

Next:From: Stephen FrostDate: 2009-04-22 12:44:44
Subject: Re: performance for high-volume log insertion
Previous:From: roopabenzerDate: 2009-04-22 07:16:12
Subject: Re: probelm with alter table add constraint......

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