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:18:48
Message-ID: 201012292018.oBTKIml15015@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2010-12-29 20:20:40 Re: SSI SLRU strategy choices
Previous Message Bruce Momjian 2010-12-29 20:11:18 Re: Anyone for SSDs?