I'm interested in this improvement. I'm not confident I can produce the patch on my own but would happily work with others.
As I just noted on IRC, I'd see a few features that could come from this (namely, adding another btree for attachment digests). Firstly, I'd suggest it's md5 as damien already added that with the deterministic revs patch. But, given that, we could make an attachment upload with a Content-MD5 header return a successful status code without transferring the request body. This might have security implications so might need to be a toggle. However, it would allow the disk saving to occur pre-compaction, where otherwise it would only help afterward. The other advantage to having md5's in general is the ability to verify that the sent Content-MD5 header matches the bytes receives. S3 already does this, fwiw. If there's further interest in this perhaps it needs its own thread? B On Tue, Aug 4, 2009 at 11:18 AM, Jan Lehnardt<[email protected]> wrote: > Hi Brian, > > On 4 Aug 2009, at 11:56, Brian Candler wrote: > >> P.S. You don't want to have multiple copies of attachments, so they would >> need to be stored in shared form (e.g. indexed by SHA1) - I don't know if >> this is done already. > > This optimization is not currently done. But I don't see wh we shouldn't > accept a patch that adds it :) > > Cheers > Jan > -- > >
