From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
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-11 19:09:07 |
Message-ID: | AANLkTim5tRuJQTsxr-Vp=VLnNEvkd2Nn-rpP+2WV3aQt@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 10, 2010 at 8:09 PM, Vaibhav Kaushal
<vaibhavkaushal123(at)gmail(dot)com> 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.
I don't understand what it is you are proposing. Quicksort is usually
swap based, and so the records would need to be the same size. Are
you proposing to do an in-memory sort of pointers, which reference
on-disk records? Or an on-disk sort of pointers which reference
on-disk (but somewhere else) records? If you are swapping pointers on
disk, you have to consider the write performance, not just the read
performance.
> I would like to do that (coding), but I do not have a SSD on my
> machine!
That doesn't mean you can't do the coding, it just means you can't
test the performance.
The barrier to get someone else to performance test it for you is a
lot lower than the
barrier to get someone else to write it for you and then performance
test it for you.
(But I can't test-drive it, as I don't have any computer which has
both an SSD and
a hard drive, just one or the other. And the one with SSD would be
hard to compile
PG on.)
> :( Would it be impractical to try it for me? Again I do not
> know how to test PG :(
Yeah, I think it would be impractical. If I thought it would likely
work, it would be different (at least, it might be if I had the right
hardware).
But I think it would likely not work.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2010-12-11 19:53:27 | Re: unlogged tables |
Previous Message | tv | 2010-12-11 18:58:53 | keeping a timestamp of the last stats reset (for a db, table and function) |