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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
