From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Cc: | Agent M <agentm(at)themactionfaction(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-23 03:34:38 |
Message-ID: | Pine.LNX.4.58.0606231327100.353@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 22 Jun 2006, Jonah H. Harris wrote:
> Not in all systems. A few now perform in-memory UNDO and only write
> it to disk if and when it is required.
Interesting...
>
> > Overwriting MVCC comes with its own baggage. Ask any Oracle user about
> > error ORA-01555[1]. There's also the added cost of managing the UNDO logs,
> > the cost of jumping around between files to get row versions and so on.
>
> This seems to be going in the direction of our common MySQL
> discussions; relying on old failures and mistakes to base our
> assumptions on the current version. Please stay apprised of current
> developments in other systems.
Erm. Perhaps a poor example as I was not trying to put Oracle in a poor
light. Rather, I was trying to point out that each method has its
disadvantages. If the update in place method has no detractions we
shouldn't be hanging on to our existing mechanism.
> > J. Gray & A Reuter, Transaction Processing: Concepts and Techniques
>
> Pretty much older than dirt, discusses locking, and barely touches on
> MVCC. Still has some good concepts though.
The really useful section of this book is the discussion of snapshot
isolation. That's the important thing here. Conceivably we could have a
higher performance storage system but, IMHO, it must implement snapshot
isolation.
Thanks,
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-06-23 03:37:44 | Re: vacuum, performance, and MVCC |
Previous Message | Jonah H. Harris | 2006-06-23 03:20:24 | Re: vacuum, performance, and MVCC |