On Fri, Dec 10, 2010 at 8:09 PM, Vaibhav Kaushal
> 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
> I would like to do that (coding), but I do not have a SSD on my
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
> :( 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
But I think it would likely not work.
In response to
pgsql-hackers by date
|Next:||From: Jeff Janes||Date: 2010-12-11 19:53:27|
|Subject: Re: unlogged tables|
|Previous:||From: tv||Date: 2010-12-11 18:58:53|
|Subject: keeping a timestamp of the last stats reset (for a db, table and