On Wed, Aug 4, 2010 at 5:09 PM, Nilson <nilson.bra...@gmail.com> wrote: > The prices of large capacity Solid State Disks (SLCs of course) are still > too high to most of us. > > But it´s already possible to find SSDs of small size (8 to 32 GB) today with > affordable prices and good performance (0,1ms access time and at least > 150MB/s r/w transfer rate). > > So, would it possible to use these Small Size SSDs (S5Ds) as a buffer to > improve postgreSQL's write performance? > > For now, I detected two opportunities: > > 1) usage of a S5D to temporarily store the WAL log files until a deamon > process copy them to the regular HD. > > 2) usage of a S5D to store instructions to a make a checkpoint. Instead of > write the "dirty" pages directly to database files, postgreSQL could dump to > SSD the dirty pages and the instructions of how update the data files. > Later, a deamon process would update the files following these instructions > and erase the instruction files after that. I guess that MVCC induces the > spread of writes along the file area, requiring lots of seeks to find the > correct disk block. So SSDs will produce a good performance in burst > situation. > > I guess these ideas could improve the write performance significantly (3x to > 50x) in databases systems that perform writes with SYNC and have many write > bursts or handle large (20MB+) BLOBs (many WAL segments and pages to write > on checkpoint). > > Of course, postgreSQL should be patched to handle, not only with the new > behaviours, but to handle a possible SSD full. > > One solution to (1) could be a fast/main volume scheme. In case of the fast > volume full condition, postgreSQL should use the main volume. > > The (2) solution is more delicate because introduce a new type of file to > hold data. But, if the gain worths, it should be examinated ... > > Well, that´s it.
This is offtopic for -hackers...better -general or -performance. In fact, there is a long highly informative topic on SSDs going on right now which you might be interested in reading. The real short answer to your question is that $/gb is not the only metric, and the current situation with flash SSD is much more complex than it appears on the surface (for example, they basically suck without write buffering). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers