Date: Wed, 31 May 2006 01:29:08 -0500
From: "Jim C. Nasby" <jnasby@pervasive.com>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
Cc: Dave Dutcher <dave@tridecap.com>, lists@peufeu.com,
	pgsql-performance@postgresql.org
Subject: Re: INSERT OU UPDATE WITHOUT SELECT?
Message-ID: <20060531062908.GH53487@pervasive.com>
References: <op.tadyc1jwcigqcu@apollo13>
	<039201c6843b$f11eeaf0$8300a8c0@tridecap.com>
	<20060530190508.aa47bafe.darcy@druid.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20060530190508.aa47bafe.darcy@druid.net>
User-Agent: Mutt/1.5.11

On Tue, May 30, 2006 at 07:05:08PM -0400, D'Arcy J.M. Cain wrote:
> On Tue, 30 May 2006 17:54:00 -0500
> "Dave Dutcher" <dave@tridecap.com> wrote:
> > What I do when I'm feeling lazy is execute a delete statement and then
> > an insert.  I only do it when I'm inserting/updating a very small number
> > of rows, so I've never worried if its optimal for performance.  Besides
> > I've heard that an update in postgres is similar in performance to a
> > delete/insert.
> 
> Well, they are basically the same operation in PostgreSQL.  An update
> adds a row to the end and marks the old one dead.  A delete/insert
> marks the row dead and adds one at the end.  There may be some
> optimization if the engine does both in one operation.

The new tuple will actually go on the same page during an update, if
possible. If not, the FSM is consulted. Appending to the end of the
table is a last resort.

Update is more effecient than delete/insert. First, it's one less
statement to parse and plan. Second, AFAIK insert always goes to the
FSM; it has no way to know you're replacing the row(s) you just deleted.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461