Using Small Size SSDs to improve performance? - Mailing list pgsql-hackers

From Nilson
Subject Using Small Size SSDs to improve performance?
Date
Msg-id AANLkTiknzwjXNVJe0jsLiakdzCOQFo-tiEO5jkeQPagZ@mail.gmail.com
Whole thread Raw
Responses Re: Using Small Size SSDs to improve performance?  (Merlin Moncure <mmoncure@gmail.com>)
Re: Using Small Size SSDs to improve performance?  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
The prices of large capacity Solid State Disks (SLCs of course) are still too high to most of us.<br /><br />But it´s
alreadypossible to find SSDs of small size (8 to 32 GB) today with affordable prices and good performance (0,1ms access
timeand at least 150MB/s r/w transfer rate).<br /><br />So, would it possible to use these Small Size SSDs (S5Ds) as a
bufferto improve postgreSQL's write performance?<br /><br />For now, I detected two opportunities:<br /><br />1) usage
ofa S5D to temporarily store the WAL log files until a deamon process copy them to the regular HD. <br /><br />2) usage
ofa S5D to store instructions to a make a checkpoint. Instead of write the "dirty" pages directly to database files,
postgreSQLcould dump to SSD the dirty pages and the instructions of how update the data files. Later, a deamon process
wouldupdate the files following these instructions and erase the instruction files after that.  I guess that MVCC
inducesthe spread of writes along the file area, requiring lots of seeks to find the correct disk block. So SSDs will
producea good performance in burst situation.<br /><br />I guess these ideas could improve the write performance <font
size="2"><spanclass="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family:
arial,helvetica,sans-serif;font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height:normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing:
0px;"><spanclass="Apple-style-span" style="line-height: 25px;">significantly</span></span></font> (3x to 50x) in
databasessystems that perform writes with SYNC and have many write bursts or handle large (20MB+) BLOBs (many WAL
segmentsand pages to write on checkpoint). <br /><br />Of course, postgreSQL should be patched to handle, not only with
thenew behaviours, but to handle a possible SSD full. <br /><br />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.<br /><br />The (2) solution is
moredelicate because introduce a new type of file to hold data. But, if the gain worths, it should be examinated ...<br
/><br/>Well, that´s it.<br /><br /><br clear="all" /><br />-- <br />Nilson<br /> 

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
Next
From: "Kevin Grittner"
Date:
Subject: Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname