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


From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
Cc: Dave Dutcher <dave(at)tridecap(dot)com>, lists(at)peufeu(dot)com,pgsql-performance(at)postgresql(dot)org
Date: 2006-05-31 06:29:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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(at)tridecap(dot)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(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to

pgsql-performance by date

Next:From: Brendan DuddridgeDate: 2006-05-31 06:29:50
Subject: Re: App very unresponsive while performing simple update
Previous:From: Jim C. NasbyDate: 2006-05-31 06:23:07
Subject: Re: App very unresponsive while performing simple update

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