Re: Storage Manager (was postgres 7.2 features.)

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Storage Manager (was postgres 7.2 features.)
Date: 2000-07-11 10:09:14
Message-ID: 200007111009.MAA16886@hot.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Bitmead wrote:
>
> Has sufficient research been done to warrant destruction of what is
> currently there?

What's currently there doesn't have TT any more. So there is
nothing we would destroy with an overwriting SMGR.

> According to the postgres research papers, the no-overwrite storage
> manager has the following attributes...

I started using (and hacking) Postgres in version 4.2, which
was the last official release from Stonebrakers team at UCB
(and the last one with the PostQUEL query language).

The no-overwriting SMGR concept was one of the things, the
entire project should aprove. The idea was to combine
rollback and logging information with the data itself, by
only storing new values and remembering when something
appeared or disappeared. Stable memory just means "if I know
my write made it to some point, I can read it back later even
in the case of a crash".

This has never been implemented to a degree that is capable
to catch hardware failures like unexpected loss of power. So
the project finally told "it might be possible". Many other
questions have been answered by the project, but exactly this
one is still open.

> * It's always faster than WAL in the presence of stable main memory.
> (Whether the stable caches in modern disk drives is an approximation I
> don't know).

For writing, yes. But for high updated tables, the scans will
soon slow down due to the junk contention.

> * It's more scalable and has less logging contention. This allows
> greater scalablility in the presence of multiple processors.
>
> * Instantaneous crash recovery.

Because this never worked reliable, Vadim is working on WAL.

> * Time travel is available at no cost.
>
> * Easier to code and prove correctness. (I used to work for a database
> company that implemented WAL, and it took them a large number of years
> before they supposedly corrected every bug and crash condition on
> recovery).
>
> * Ability to keep archival records on an archival medium.

Has this ever been implemented?

> Is there any research on the level of what was done previously to
> warrant abandoning these benefits? Obviously WAL has its own benefits, I
> just don't want to see the current benefits lost.

I see your points. Maybe we can leave the no-overwriting SMGR
in the code, and just make the new one the default.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Elphick 2000-07-11 10:29:54 Re: Slashdot discussion
Previous Message Jan Wieck 2000-07-11 09:20:19 Re: [HACKERS] Foreign key bugs (Re: "New" bug?? Serious - crashes backend.)