On Wed, Apr 26, 2006 at 10:43:48AM -0400, Michael Stone wrote:
patch a 512k blocksize would get ~100MB/s. I'm now watching to see how
it does over a couple of days on real-world workloads.
I've got one DB where the VACUUM ANALYZE generally takes 11M-12M ms;
with the patch the job took 1.7M ms.
(including bizgres-general)
Has anyone done any testing on bizgres? It's got some patches that
eliminate a lot of IO bottlenecks, so it might present even larger
gains.
On Wed, Apr 26, 2006 at 03:08:59PM -0500, Steve Poe wrote:
> I found an average 14% improvement Using Pg 7.4.11 with odbc-bench
I found an average 14% improvement Using Pg 7.4.11 with odbc-bench as my
test bed with Wu's kernel patch. I have not tried version 8.x yet.
Thanks Wu.
Steve Poe
Using Postgresql 7.4.11, on an dual Opteron with 4GB
On Fri, 2006-04-21 at 09:38 +0800, Wu Fengguang wrote:
> Greetings,
>
> I'd li
From my initial testing this is very promising for a postgres server.
Benchmark-wise, a simple dd with an 8k blocksize gets ~200MB/s as
compared to ~140MB/s on the same hardware without the patch. Also, that
200MB/s seems to be unaffected by the dd blocksize, whereas without the
patch a 512k bl
Greetings,
I'd like to introduce a new readahead framework of the linux kernel:
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1021.html
HOW IT WORKS
In adaptive readahead, the context based method may be of particular
interest to postgresql users. It works by peeking into the file cache
a
On Fri, Apr 21, 2006 at 01:34:24PM -0500, Jim C. Nasby wrote:
> IIRC Mark from OSDL said he'd try testing this when he gets a chance,
> but you could also try running dbt2 and dbt3 against it.
Thanks for the info, I'll look into them.
Regards,
wu
---(end of broadcast)
On Fri, Apr 21, 2006 at 08:20:28PM +0800, Wu Fengguang wrote:
> Hi Markus,
>
> On Fri, Apr 21, 2006 at 09:53:34AM +0200, Markus Schaber wrote:
> > Are there any rough estimates when this will get into mainline kernel
> > (if you intend to submit)?
>
> I'm not quite sure :)
>
> The patch itself h
Hi Markus,
On Fri, Apr 21, 2006 at 09:53:34AM +0200, Markus Schaber wrote:
> Are there any rough estimates when this will get into mainline kernel
> (if you intend to submit)?
I'm not quite sure :)
The patch itself has been pretty stable. To get it accepted, we must
back it by good benchmarking
Hi, Wu,
Wu Fengguang wrote:
>>>In adaptive readahead, the context based method may be of particular
>>>interest to postgresql users. It works by peeking into the file cache
>>>and check if there are any history pages present or accessed. In this
>>>way it can detect almost all forms of sequential
On Thu, Apr 20, 2006 at 11:31:47PM -0500, Jim C. Nasby wrote:
> > In adaptive readahead, the context based method may be of particular
> > interest to postgresql users. It works by peeking into the file cache
> > and check if there are any history pages present or accessed. In this
> > way it can d
On Fri, Apr 21, 2006 at 09:38:26AM +0800, Wu Fengguang wrote:
> Greetings,
>
> I'd like to introduce a new readahead framework for the linux kernel:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1021.html
>
> HOW IT WORKS
>
> In adaptive readahead, the context based method may be of par
Greetings,
I'd like to introduce a new readahead framework for the linux kernel:
http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1021.html
HOW IT WORKS
In adaptive readahead, the context based method may be of particular
interest to postgresql users. It works by peeking into the file cache
12 matches
Mail list logo
