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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
