[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] space saving in the database

In response to Marc Cousin <cousinmarc@xxxxxxxxx>:

> On Monday 11 February 2008 20:46:09 Bill Moran wrote:
> > In response to Marc Cousin <cousinmarc@xxxxxxxxx>:
> >
> > [snip]
> >
> > > Still, I'd like to know if the md5 field is always a multiple of 32 bits
> > > in length ?
> >
> > md5 is _always_ exactly 128 bits.  It's frequently represented as a 32
> > character hex string, but that's just a friendly way to display it.
> >
> > If you use a bytea field (for example) you can lock it in at 128 bits.
> > That will help overall by only taking up 20 bytes instead of 36 bytes
> > for the text string representation, but you have the 4-byte length
> > header either way.
> Yes but in the md5 field, we can also have sha1 or sha256. And maybe something 
> else in the future ?
> Those 3 are 128, 160 and 256 bits, so they are ok for my algorithm... I bet I 
> should just work with this assumption

Just thought of something else.  With Postgres, the DB also does
compression behind the scenes.  An md5 (or sha1 or anything else for
that matter) is probably going to compress down to the same size
regardless of how it's represented (since it's the same amount of
entropy) ... so you're probably not going to gain anything by messing
with the representation.

I don't know how much of this applies to MySQL.

Bill Moran
Collaborative Fusion Inc.

Phone: 412-422-3463x4023

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.