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

Re: performance of insert/delete/update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance of insert/delete/update
Date: 2002-11-26 03:30:23
Message-ID: 5163.1038281423@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> writes:
> On Mon, 2002-11-25 at 18:23, scott.marlowe wrote:
>> The next factor that makes for fast inserts of large amounts of data in a 
>> transaction is MVCC.  With Oracle and many other databases, transactions 
>> are written into a seperate log file, and when you commit, they are 
>> inserted into the database as one big group.  This means you write your 
>> data twice, once into the transaction log, and once into the database.

> You are just deferring the pain.  Whereas others must flush from log
> to "database files", they do not have to VACUUM or VACUUM ANALYZE.

Sure, it's just shuffling the housekeeping work from one place to
another.  The thing that I like about Postgres' approach is that we
put the housekeeping in a background task (VACUUM) rather than in the
critical path of foreground transaction commit.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2002-11-26 03:44:29
Subject: Re: performance of insert/delete/update
Previous:From: Ron JohnsonDate: 2002-11-26 01:52:33
Subject: Re: performance of insert/delete/update

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-11-26 03:44:29
Subject: Re: performance of insert/delete/update
Previous:From: Bruce MomjianDate: 2002-11-26 03:09:41
Subject: dbmirror had sprintf string too short

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