Thread: RE: Proposal: replace no-overwrite with Berkeley DB

> Perhaps what you are talking about is at so low a level that it
> has no influence on these features...but if not then it might be 
> that the writer of a WAL will want to write an implementation of
> the storage manager that is well integrated with the WAL.

Yes, I would like to do this, if everyone agreed to wait for
7.2. Actually, I'm not sure if we're able to make both smgr
and WAL in 7.1

Vadim

> > Perhaps what you are talking about is at so low a level that it
> > has no influence on these features...but if not then it might be
> > that the writer of a WAL will want to write an implementation of
> > the storage manager that is well integrated with the WAL.
> Yes, I would like to do this, if everyone agreed to wait for
> 7.2. Actually, I'm not sure if we're able to make both smgr
> and WAL in 7.1

istm that future work on distributed databases would require some
generic API layer, perhaps identical to the current smgr layer or
perhaps something higher up. Maybe an alternate local storage scheme
could plug into that same interface, much as storage managers used to
do.

If this is accurate, then someone could demonstrate the sleepycat code
without having to impact other parts of the code?
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> istm that future work on distributed databases would require some
> generic API layer, perhaps identical to the current smgr layer or
> perhaps something higher up. Maybe an alternate local storage scheme
> could plug into that same interface, much as storage managers used to
> do.
> If this is accurate, then someone could demonstrate the sleepycat code
> without having to impact other parts of the code?

As far as I can tell, the current smgr switch is at a much lower level
than the Berkeley DB API is --- smgr's API involves reading and writing
disk blocks, and the contents of those blocks is the concern of higher
levels like bufmgr and the various access methods.  BDB would want to
replace most of the access-method layer, not to mention bufmgr, lockmgr,
a lot of the shmem code, and maybe parts of transam.  We don't have a
single API that covers that territory, and I'm not sure it'd be
reasonable to try to make one.

Another problem is that we've been kinda sloppy about preserving purity
of the APIs that we have --- for example, relation rename ought to be
done via an smgr call, but instead it's been hacked into higher-level
code.  Cleaning up that sort of thing would be a good idea in any case,
but it's just part of the work you'd have to do before you could think
about plugging in BDB.
        regards, tom lane