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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-26 03:44:29 | Re: performance of insert/delete/update |
Previous Message | Bruce Momjian | 2002-11-26 03:09:41 | dbmirror had sprintf string too short |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-26 03:44:29 | Re: performance of insert/delete/update |
Previous Message | Ron Johnson | 2002-11-26 01:52:33 | Re: performance of insert/delete/update |