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,
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
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 for a
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
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
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
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.
When
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't see an
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
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 PROTECTED]
* 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 complete.
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 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
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 works fine
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 mutually exclusive
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
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.
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 DBA
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 showed
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 reason to
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 was
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 is
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
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
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 on
, 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 suggestions
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.
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 already
discussed
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
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.) parallel
30 matches
Mail list logo
