Robert Treat wrote: > > > What _is_ interesting is that Postgres often has sequential and > > > random/disk ways of doing things, and by reducing random_page_cost when > > > using SSDs, you automatically use more random operations, so in a way > > > the Postgres code was already prepared for SSD usage. Surprisingly, we > > > had to change very little. > > > > To add to this very late reply, we basically had random methods to do > > things (in RAM), and sequential/random methods for disk. By changing > > random_page_cost, we favor doing random things on disk. > > > > The big question is whether there are random things we have never > > implemented on disk that now make sense --- off hand, I can't think of > > any. > > > > > The idea of us avoiding quicksort when we know we need to spill to disk is
You mean using quicksort from an (SSD) disk vs. tape sorts --- good point. > the type of thing that I wonder if it should be investigated, if you figure > that "spill to disk" means ssd's so it's not so much of a performance > hit. This reminds me of some performance testing we did maybe a year, year > and a half ago, trying to see how best to get performance by adding some > SSD's into one of our servers. Basically speed increased as we changed > things like so: > put entire $pgdata on sata > put entire $pgdata on ssd > put xlogs on ssd, pgdata on sata > put pgdata and xlogs on sata, put arc on ssd, crank up postgres's memory > settings > > arc being zfs's adaptive replacement cache, so basically giving the server a > second, very large level of memory to work with, and then configuring > postgres to make use of it. It wasn't terribly obvious to me why this ended > up outperforming the initial idea of putting everything on ssd, but my > impression was that the more you could force postgres into making decisions > as if it was dealing with fast storage rather than slow storage, the better > off you'd be (and that random_page_cost is not so wholly inclusive enough to > do this for you). Yes, I wonder if this requires futher investigation. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers