Re: Storage Manager (was postgres 7.2 features.) - Mailing list 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
teamat 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
readit 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,
butexactly 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 #