Re: Multi CPU Queries - Feedback and/or suggestions wanted!

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, 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 02:42:30
Message-ID: 200810240242.m9O2gUm27350@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark wrote:
> I couldn't get async I/O to work on Linux. That is it "worked" but
> performed the same as reading one block at a time. On solaris the
> situation is reversed.
>
> In what way is fadvise a kludge?

I think he is saying AIO gives us more flexibility, but I am unsure we
need it.

---------------------------------------------------------------------------

>
> greg
>
> On 24 Oct 2008, at 01:44 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > 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. +
> >
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers

--
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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2008-10-24 03:29:37 Re: Multi CPU Queries - Feedback and/or suggestions wanted!
Previous Message Greg Stark 2008-10-24 02:36:31 Re: Multi CPU Queries - Feedback and/or suggestions wanted!