Re: SSD performance
От
david@lang.hm
Тема
Re: SSD performance
Дата
Msg-id
alpine.DEB.1.10.0901262349490.16162@asgard.lang.hm
Ответ на
Re: SSD performance (James Mansion)
Список
Дерево обсуждения
SSD performance david@lang.hm
Re: SSD performance Glyn Astill <glynastill@yahoo.co.uk>
Re: SSD performance david@lang.hm
Re: SSD performance Merlin Moncure <mmoncure@gmail.com>
Re: SSD performance david@lang.hm
Re: SSD performance Greg Smith <gsmith@gregsmith.com>
Re: SSD performance david@lang.hm
Re: SSD performance Gregory Stark <stark@enterprisedb.com>
Re: SSD performance david@lang.hm
Re: SSD performance Scott Carey <scott@richrelevance.com>
Re: SSD performance Jeff <threshar@torgo.978.org>
Re: SSD performance David Rees <drees76@gmail.com>
Re: SSD performance Scott Carey <scott@richrelevance.com>
Re: SSD performance Jeff <threshar@torgo.978.org>
Re: SSD performance david@lang.hm
Re: SSD performance Scott Marlowe <scott.marlowe@gmail.com>
Re: SSD performance Matthew Wakeling <matthew@flymine.org>
On Tue, 27 Jan 2009, James Mansion wrote: > Craig Ringer wrote: >> These devices would be interesting for a few uses, IMO. One is temp >> table space and sort space in Pg. Another is scratch space for apps >> (like Photoshop) that do their own VM management. There's also potential >> > Surely temp tables and sort space isn't subject to fsync and won't gain that > much since they > should stay in the OS cache? The device will surely help seek- or sync-bound > tasks. > > Doesn't that make it a good candidate for WAL and hot tables? it doesn't just gain on fsync speed, but also raw transfer speed. if everything stays in the OS buffers than you are right, but when you start to exceed those buffers is when fast storage like this is very useful. David Lang
В списке pgsql-performance по дате отправления