From: Marc C. <cou...@gm...> - 2008-02-11 20:18:19
|
On Monday 11 February 2008 21:13:17 Bill Moran wrote: > In response to Marc Cousin <cou...@gm...>: > > On Monday 11 February 2008 20:46:09 Bill Moran wrote: > > > In response to Marc Cousin <cou...@gm...>: > > > > > > [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. Postgresql only compresses when the field is bigger than 2kb (via toast) see : http://www.postgresql.org/docs/8.2/interactive/storage-toast.html |