Re: Storage Manager (was postgres 7.2 features.)

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@Yahoo.com #