Skip site navigation (1) Skip section navigation (2)

Re: Anyone for SSDs?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Treat <rob(at)xzilla(dot)net>
Cc: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Anyone for SSDs?
Date: 2011-01-01 20:58:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

> 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(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2011-01-01 21:21:34
Subject: SSI SLRU low-level functions first cut
Previous:From: Bruce MomjianDate: 2011-01-01 20:55:43
Subject: Re: TODO item for pg_ctl and server detection

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group