Using Small Size SSDs to improve performance?

From: Nilson <nilson(dot)brazil(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Using Small Size SSDs to improve performance?
Date: 2010-08-04 21:09:13
Message-ID: AANLkTiknzwjXNVJe0jsLiakdzCOQFo-tiEO5jkeQPagZ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Nilson

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-08-04 21:13:21 Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname
Previous Message Merlin Moncure 2010-08-04 20:42:30 Re: Drop one-argument string_agg? (was Re: string_agg delimiter having no effect with order by)