From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Kyriacos Kyriacou <kyriacosk(at)prime-tel(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: MVCC performance issue |
Date: | 2010-11-14 08:30:37 |
Message-ID: | AANLkTim3RkKFQYGaXEs=4N=Fz26=4NuinQXhsSFD7Y6V@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, Nov 13, 2010 at 07:53, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:
> Oracle's MVCC approach has its own costs. Like Pg's, those costs increase
> with update/delete frequency. Instead of table bloat, Oracle suffers from
> redo log growth (or redo log size management issues). Instead of increased
> table scan costs from dead rows, Oracle suffers from random I/O costs as it
> looks up the out-of-line redo log for old rows. Instead of long-running
> writer transactions causing table bloat, Oracle can have problems with
> long-running reader transactions aborting when the redo log runs out of
> space.
Another advantage of Oracle's approach seems that they need much less
tuple-level overhead. IMO the 23-byte tuple overhead is a much bigger
drawback in Postgres than table fragmentation.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Marti Raudsepp | 2010-11-14 08:46:14 | Re: MVCC performance issue |
Previous Message | Robert Haas | 2010-11-14 02:54:58 | Re: temporary tables, indexes, and query plans |