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. +
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? |