Bruce Momjian wrote:
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, b
>Hi Simon,
>
>He is going to do some investigation in the methods and
>write down the possibilities and then he is going to implement
>something from that for PostgreSQL.
>
>When will this work be complete? We are days away from completing main
>work on 8.4, so you won't get much discussion on this
Hi Simon,
He is going to do some investigation in the methods and
write down the possibilities and then he is going to implement
something from that for PostgreSQL.
When will this work be complete? We are days away from completing main
work on 8.4, so you won't get much discussion on this
* Greg Stark <[EMAIL PROTECTED]> [081024 10:48]:
> I thought about how to support both and ran into probblems that would
> make the resulting solutions quite complex.
>
> In the libaio view of the world you initiate io and either get a
> callback or call another syscall to test if it's complet
Also keep in mind that solaris is open source these days. If someone
wants it they could always go ahead and add the feature ...
greg
On 24 Oct 2008, at 03:18 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Jonah H. Harris wrote:
On Fri, Oct 24, 2008 at 7:59 AM, Hannu Krosing
<[EMAIL PROTECTE
I thought about how to support both and ran into probblems that would
make the resulting solutions quite complex.
In the libaio view of the world you initiate io and either get a
callback or call another syscall to test if it's complete. Either
approach has problems for postgres. If the pro
Jonah H. Harris wrote:
> On Fri, Oct 24, 2008 at 7:59 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> > On Fri, 2008-10-24 at 00:52 -0400, Jonah H. Harris wrote:
> >> While we could build an
> >> abstract prefetch interface and simply use fadvise for it now (rather
> >> than OS-specific code), I don
On Fri, Oct 24, 2008 at 7:59 AM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> On Fri, 2008-10-24 at 00:52 -0400, Jonah H. Harris wrote:
>> While we could build an
>> abstract prefetch interface and simply use fadvise for it now (rather
>> than OS-specific code), I don't see an easy win in any case.
>
On Fri, 2008-10-24 at 00:52 -0400, Jonah H. Harris wrote:
> While we could build an
> abstract prefetch interface and simply use fadvise for it now (rather
> than OS-specific code), I don't see an easy win in any case.
When building an abstract interface, always use at least two
implementations (I
Jonah H. Harris wrote:
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
True, it is a kludge but if it gives us 95% of the benfit with 10% of
the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
Let's
Jonah H. Harris wrote:
fadvise is a kludge.
I don't think it's a kludge at all. posix_fadvise() is a pretty nice and
clean interface to hint the kernel what pages you're going to access in
the near future. I can't immediately come up with a cleaner interface to
do that.
Compared to async I
We did discuss this in Ottawa and I beleive your comment was "the hint
is in the name" referring to posix_fadvise.
In any case both aio and posix_fadvise are specified by posix so I
don't see either as a problem on that front.
I don't think we can ignore any longer that we effectively can't
Based on what? I did test this and posted the data. The results I
posted showed that posix_fadvise on Linux performed nearly as well on
Linux as async I/O on Solaris on identical hardware.
More importantly it scaled with the number if drives. A 15 drive array
gets about 15x the performance
On 24 Oct 2008, at 04:31 AM, "Jonah H. Harris"
<[EMAIL PROTECTED]> wrote:
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
<[EMAIL PROTECTED]> 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
On Fri, Oct 24, 2008 at 12:42 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> non-portable, requires more user-to-system CPU, ... need I go on?
>
> I'd be interested to know which of these proposals you claim *is*
> portable. The single biggest reason to reject 'em all is that
> they aren't.
Yes, that
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
>> In what way is fadvise a kludge?
> non-portable, requires more user-to-system CPU, ... need I go on?
I'd be interested to know which of these proposals you claim *is*
portable. The single biggest reas
On Thu, Oct 23, 2008 at 10:36 PM, Greg Stark
<[EMAIL PROTECTED]> 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.
Hmm, then obviously you did something wrong, because my tests sh
On Thu, Oct 23, 2008 at 8:44 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> True, it is a kludge but if it gives us 95% of the benfit with 10% of
> the code, it is a win.
I'd say, optimistically, maybe 30-45% the benefit over a proper
multi-block read using O_DIRECT.
--
Jonah H. Harris, Senior D
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
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?
greg
On 24 Oct 2008, at 01:44 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Jonah H. Harris wrote:
On
Jonah H. Harris wrote:
> On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith <[EMAIL PROTECTED]> 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 mut
On Thu, Oct 23, 2008 at 4:53 PM, Greg Smith <[EMAIL PROTECTED]> 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 w
On Thu, 23 Oct 2008, Bruce Momjian 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
Julius Stroffek wrote:
> Hi All,
>
> we would like to start some work on improving the performance of
> PostgreSQL in a multi-CPU environment. Dano Vojtek is student at the
> Faculty of Mathematics and Physics of Charles university in Prague
> (http://www.mff.cuni.cz) and he is going to cover this
On Mon, 2008-10-20 at 21:05 +0200, Julius Stroffek wrote:
> He is going to do some investigation in the methods and
> write down the possibilities and then he is going to implement
> something from that for PostgreSQL.
When will this work be complete? We are days away from completing main
work o
25
To: Julius Stroffek
Cc: pgsql-hackers@postgresql.org; Dano Vojtek
Subject: Re: [HACKERS] Multi CPU Queries - Feedback and/or
suggestions wanted!
On Mon, Oct 20, 2008 at 12:05 PM, Julius Stroffek <[EMAIL PROTECTED]
> wrote:
Topics that seem to be of interest and most of them were alread
Hi Jeffrey,
thank you for the suggestion. Yes, they potentially can, we'll consider
this.
Julo
Jeffrey Baker wrote:
I don't see why multiple CPUs can't work on the same node of a plan.
For instance, consider a node involving a scan with an expensive
condition, like UTF-8 string length. If
table, but not to all platforms. (Yes, they do work on Windows)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Baker
Sent: 2008-10-20 22:25
To: Julius Stroffek
Cc: pgsql-hackers@postgresql.org; Dano Vojtek
Subject: Re: [HACKERS] Multi CPU Queries - Feedback and/or s
On Mon, Oct 20, 2008 at 12:05 PM, Julius Stroffek
<[EMAIL PROTECTED]>wrote:
> Topics that seem to be of interest and most of them were already
> discussed at developers meeting in Ottawa are
> 1.) parallel sorts
> 2.) parallel query execution
> 3.) asynchronous I/O
> 4.) parallel COPY
> 5.) parall
Hi All,
we would like to start some work on improving the performance of
PostgreSQL in a multi-CPU environment. Dano Vojtek is student at the
Faculty of Mathematics and Physics of Charles university in Prague
(http://www.mff.cuni.cz) and he is going to cover this topic in his
master thesis. He is
30 matches
Mail list logo