From: | Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Anyone for SSDs? |
Date: | 2010-12-10 12:52:43 |
Message-ID: | 1291985563.8313.9.camel@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2010-12-10 at 07:38 -0500, Robert Haas wrote:
> On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
> <vaibhavkaushal123(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.
> >
> > This came suddenly in my mind so I am asking the experts here.
> >
> > Considering the fact that SSDs will be common (at least for the
> > enterprise) in the coming years because of (of course you know the
> > reason) their less seek time and higher transfer rates per second, is
> > there someone trying for a ssd.c? In almost all cases even using md.c,
> > the kernel will handle it effectively but would it not be better that we
> > are well prepared to ask kernel for more?
> >
> > Or has such an attempt already begun?
>
> Questions about using SSDs with PostgreSQL would be more appropriate
> on pgsql-performance, rather than here. If you search, you'll find
> that the topic has been covered extensively in the archives.
>
> But as far as the code goes, there doesn't seem to be any reason why
> SSDs would require any changes to md.c, or an alternate
> implementation. The interface the operating system presents is the
> same.
>
OK. Thanks a lot. I have not joined that list so I asked it here. :)
Will check that out.
- Vaibhav (*_*)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-12-10 13:45:44 | Re: BufFreelistLock |
Previous Message | Andrew Dunstan | 2010-12-10 12:50:13 | Re: initdb failure with Postgres 8.4.4 |