From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
Cc: | Greg Smith <gsmith(at)gregsmith(dot)com>, Julius Stroffek <Julius(dot)Stroffek(at)sun(dot)com>, pgsql-hackers(at)postgresql(dot)org, Dano Vojtek <danielkov(at)gmail(dot)com> |
Subject: | Re: Multi CPU Queries - Feedback and/or suggestions wanted! |
Date: | 2008-10-24 00:44:14 |
Message-ID: | 200810240044.m9O0iEZ09064@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jonah H. Harris wrote:
> On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> >> I think the current plan is to use posix_advise() to allow parallel I/O,
> >> rather than async I/O becuase posix_advise() will require fewer code
> >> changes.
> >
> > These are not necessarily mutually exclusive designs. fadvise works fine on
> > Linux, but as far as I know only async I/O works on Solaris. Linux also has
> > an async I/O library, and it's not clear to me yet whether that might work
> > even better than the fadvise approach.
>
> fadvise is a kludge. While it will help, it still makes us completely
> reliant on the OS. For performance reasons, we should be supporting a
> multi-block read directly into shared buffers. IIRC, we currently
> have support for rings in the buffer pool, which we could read
> directly into. Though, an LRU-based buffer manager design would be
> more optimal in this case.
True, it is a kludge but if it gives us 95% of the benfit with 10% of
the code, it is a win.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Russell Smith | 2008-10-24 01:21:29 | Re: SSL README |
Previous Message | Bruce Momjian | 2008-10-24 00:43:40 | Re: SSL README |