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
