From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Lukas Kahwe Smith <smith(at)pooteeweet(dot)org> |
Cc: | Decibel! <decibel(at)decibel(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-advocacy(at)postgresql(dot)org |
Subject: | Re: PostgreSQL vs. MySQL: fight |
Date: | 2007-08-13 18:08:15 |
Message-ID: | 1187028495.27681.62.camel@dogma.ljc.laika.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
On Sat, 2007-08-11 at 00:06 +0200, Lukas Kahwe Smith wrote:
> > Is there a document explaining more of the differences between the
> > postgresql MVCC model and something closer to InnoDB or Oracle, where it
> > has rollback segments? I'm interested in the design tradeoffs between
> > the two ideas.
>
> I cannot give you an exact comparison. But the PostgreSQL docs are
> pretty good on how things work there and the following article explains
> how things are in Oracle and the rest:
> http://www.ibphoenix.com/main.nfs?page=ibp_mvcc_roman
>
Thanks for the link.
If I understand correctly, the idea is that non-postgres mvcc systems
(interbase, etc) write the new version in the old location, and copy the
old tuple version to a special undo log area. Is that a reasonable
summary?
I wonder how they are able to update records when the new version takes
up more space than the old version? Also, how do they update indexes
that point to a value that has changed? And how do they reclaim storage
for deletes?
It seems like the approach of interbase, etc, has some advantages by
keeping better cluster order and reducing the need for VACUUM, but seems
like it might introduce other problems (although they don't explain what
those other problems are). Hopefully HOT is the best of all worlds.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-08-13 19:39:05 | Re: PLEASE READ FIRST! Re: Quality of email postings |
Previous Message | Greg Smith | 2007-08-13 17:20:02 | Re: L |