Re: Anyone for SSDs?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Daniel Loureiro <loureirorg(at)gmail(dot)com>
Cc: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Anyone for SSDs?
Date: 2010-12-10 22:15:46
Message-ID: AANLkTikSP2O-zo+m8L3TwkbK+xFaqtS-R7wJymeR59=K@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 10, 2010 at 12:21 PM, Daniel Loureiro <loureirorg(at)gmail(dot)com> wrote:
>>> Most of you already know I am new to this list and newer to any OSS
>>> development. However, while browsing the source code (of 9.0.1) I find
>>> that there is only one way to store relations on disk - the magnetic
>>> disk.
>
>>The fact that it's called md.c is a hangover from the '80s.  These days,
>>the logic that the Berkeley guys envisioned being at that code level
>>is generally in kernel device drivers.  md.c can drive anything that
>>behaves as a block device + filesystem, which is pretty much everything
>>of interest.
>
> I believe that PostgreSQL was been developed and optimized for
> sequential access. To get full advantage of SSDs its necessary to
> rewrite almost the whole project - there are so much code written with
> the sequential mechanism in mind.

I don't think that that is true at all. If you tell the planner that
a random page and a sequential page have the same cost, does it not
believe you?

Of course if you do a full table scan because their are no better
options, then it scans sequentially. But you have to scan the pages
in *some* order, and it is hard to see how something other than
sequential would be systematically better.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-12-10 22:22:26 Re: ALTER EXTENSION ... UPGRADE;
Previous Message Aidan Van Dyk 2010-12-10 22:02:06 Re: ALTER EXTENSION ... UPGRADE;