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

Re: Anyone for SSDs?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Anyone for SSDs?
Date: 2010-12-29 20:34:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> Vaibhav Kaushal wrote:
> > On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote: 
> > > On 12/10/10 5:06 PM, Daniel Loureiro wrote:
> > > > An quicksort method in
> > > > sequential disk its just awful to be thinking in a non SSD world, but
> > > > its possible in an SSD.
> > > 
> > > So, code it.  Shouldn't be hard to write a demo comparison.  I don't
> > > believe that SSDs make quicksort-on-disk feasible, but would be happy to
> > > be proven wrong.
> > 
> > I too do not believe it in normal case. However, considering the 'types'
> > of SSDs, it may be feasible! Asking for 'the next page and getting it'
> > has a time delay in the process. While on a regular HDD with spindles,
> > the question is "where is that page located", with SSDs, the question
> > disappears, because the access time is uniform in case of SSDs. Also,
> > the access time is about 100 times fasterm which would change quite a
> > few things about the whole process.
> 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

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to


pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-12-29 20:36:44
Subject: Re: Extensions, patch v16
Previous:From: Dimitri FontaineDate: 2010-12-29 20:33:31
Subject: Re: pg_dump --split patch

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