Re: Proposal: replace no-overwrite with Berkeley DB
От | Tom Lane |
---|---|
Тема | Re: Proposal: replace no-overwrite with Berkeley DB |
Дата | |
Msg-id | 6983.958442607@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: replace no-overwrite with Berkeley DB (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: