On Tue, 25 Mar 2008, mx wrote:
> The atom unit of flash is page(512~2048byte typically). Page are
> organized into blocks, typically of 32 or 64 pages. All read write and
> write operations happen at page granularity, but erase operations happen
> at block granularity.
You made a subtle switch here I wanted to emphasise. Your original
message suggested flash is an increasingly important storage mechanism
because flash devices like SSD drives are going to be more popular in the
future; that is true. However, what you're describing is something more
like how flash is used in raw embedded systems applications. The kinds of
SSD drives that are becoming popular for database use abstract away all of
this low-level block mess and hide it with approaches like sophisticated
write-leveling algorithms. You don't (and possibly can't) even know what
the underlying structure is like. And even if you did, the fact that
there's a always a regular operating system and filesystem underneath
PostgreSQL writes will make it undertain the writes are only touching the
tiny portion of flash you want to target anyway. They may write a whole
OS block regardless.
Accordingly, it's my opinion that while this topic is interesting and a
good one for your thesis, this particular project would not be too
valuable to the typical PostgreSQL user whether or not SSD becomes
popular. Working to optimize raw flash writes is really more of an
operating system level project than a database one. I also have my doubts
about whether you could get this done within the GSoC timeframe; better to
pick a less ambitious goal than rewriting the whole storage manager
interface I would think.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD