loureirorg@gmail.com (Daniel Loureiro) writes:
>> You can believe whatever you want, that doesn't make it true.
> completely agree. Like yours, Its just my point of view, not the reality.
>
> I agree with some points here, but I wondering how many good ideas are
> killed with the thought: "this will be a performance killer with so
> many random access, lets discarded it". An quicksort method in
> sequential disk its just awful to be thinking in a non SSD world, but
> its possible in an SSD.
>
> If in 80's the sequential access has more cost compared with random
> access will be the PostgreSQL in the same design that it have nowadays
> ?
What turns out to be surprising is that the behaviours of new kinds of
media not infrequently retrieve the usefulness of algorithms designed
for elderly sorts of media.
The entertaining one, on Postgres, has been that the behaviour of fairly
large amounts of memory, as compared to the slower access rates for disk
has led to retrieving tape-oriented algorithms from
thought-to-be-obsolete literature.
I don't think it's too likely that SSD changes this.
But what is rather interesting is that the issue *isn't* one of how fast
it is to sort things on disk - it is of how to sort in memory.
It's quite feasible to load blocks of data into memory, sort in memory,
via [some means], and then do tape merges to get the fully ordered
result that is then sequentially written out to disk.
Replacing [some means] with Quicksort is a plausible idea. I doubt it'd
be an improvement on what is already there, but there's already room for
it to work.
--
let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;;
http://linuxdatabases.info/info/nonrdbms.html
Outside of a dog, a book is man's best friend. Inside of a dog, it's
too dark to read. -Groucho Marx