Re: WAL versus Postgres (or: what goes around, comes ar ound)

>>>"Mikheev, Vadim" said:
> > Perhaps best solution will be to keep both (or three) storage
> > managers - and specify which one to use at database creation time.
> >
> > After reading the Stonebraker's paper, I could think there
> > are situations that we want the no-overwrite storage manager and
> > other where overwrite storage manager may offer better performance.
> > Wasn't Postgres originally designed to allow different storage
> > managers?
>
> Overwriting and non-overwriting smgr-s have quite different nature.
> Access methods would take care about what type of smgr is used for
> specific table/index...

In light of the discussion whether we can use Berkeley DB (or Sleepycat DB?) -
perhaps it is indeed good idea to start working on the access methods layer -
or perhaps just define more 'reasonable' SMGR layer at higher level than the
current Postgres code.

The idea is: (when) we have this storage manager layer, we could use different
storage managers (or heaps managers in current terms) to manage different
tables/databases.

My idea to use different managers at the database level comes from the fact,
that we do not have transactions that span databases, and that transactions
are probably the things that will be difficult to implement (in short time)
for heaps using different storage managers - such as one table no-overwrite,
another table WAL, third table Berkeley DB etc.

From Vadim's response I imagine he considers this easier to implement...

On the license issue - it is unlikely PostgreSQL to rip off its storage
internals to replace everything with Berkeley DB. This may have worked three
or five years ago, but the current storage manager is reasonable (especially
its crash recovery - I have not seen any other DBMS that is even close to
PostgreSQL in terms of 'cost of crash recovery' - this is anyway different
topic). But, if we have the storage manager layer, it may be possible to use
Berkeley DB as an additional access method - for databases/applications that
may make benefit of it - performance wise and where license permits.

Daniel