Balazs Wellisch wrote:
>
> Bill,
>
> Very interesting results. I'd like to command you on your honesty.
> Having started out with the intentions of proving that FreeBSD is faster
> than Linux only to find that the opposite is true must not have been
> rewarding for you. However, these unexpected
Christopher Kings-Lynne wrote:
> > I'm likely going to make this the default for PostgreSQL on FreeBSD
> > starting with 7.4 (just posted something to -hackers about this)f. If
> > you'd like to do this in your testing, just apply the following patch.
> >
> > Right now PostgreSQL defaults to 8K bl
Christopher Kings-Lynne wrote:
As with all performance tests/benchmarks, there are probably dozens or
more reasons why these results aren't as accurate or wonderful as they
should be. Take them for what they are and hopefully everyone can
learn a few things from them.
Intelligent feedback is welco
> I'm likely going to make this the default for PostgreSQL on FreeBSD
> starting with 7.4 (just posted something to -hackers about this)f. If
> you'd like to do this in your testing, just apply the following patch.
>
> Right now PostgreSQL defaults to 8K blocks, but FreeBSD uses 16K
> blocks which
> > As with all performance tests/benchmarks, there are probably dozens or
> > more reasons why these results aren't as accurate or wonderful as they
> > should be. Take them for what they are and hopefully everyone can
> > learn a few things from them.
> >
> > Intelligent feedback is welcome.
> >
Shridhar Daithankar wrote:
On 26 Aug 2003 at 21:47, Bill Moran wrote:
Hey all.
I said I was going to do it, and I finally did it.
As with all performance tests/benchmarks, there are probably dozens or
more reasons why these results aren't as accurate or wonderful as they
should be. Take them f
> >> I need to step in and do 2 things:
> SC> Thanks for posting that. Let me know if you have any questions while
> SC> doing your testing. I've found that using 16K blocks on FreeBSD
> SC> results in about an 8% speedup in writes to the database, fwiw.
>
> ok.. ignore my prior request about ho
On Thu, 28 Aug 2003, Sean Chittenden wrote:
> > What it still leaves quite open is just what happens when the OS has
> > more than one disk drive or CPU to play with. It's not clear what
> > happens in such cases, whether FreeBSD would catch up, or be "left
> > further in the dust." The traditio
> "SC" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I need to step in and do 2 things:
SC> Thanks for posting that. Let me know if you have any questions while
SC> doing your testing. I've found that using 16K blocks on FreeBSD
SC> results in about an 8% speedup in writes to the databas
> "SC" == Sean Chittenden <[EMAIL PROTECTED]> writes:
>> I need to step in and do 2 things:
SC> Thanks for posting that. Let me know if you have any questions while
SC> doing your testing. I've found that using 16K blocks on FreeBSD
SC> results in about an 8% speedup in writes to the databas
> I need to step in and do 2 things:
Thanks for posting that. Let me know if you have any questions while
doing your testing. I've found that using 16K blocks on FreeBSD
results in about an 8% speedup in writes to the database, fwiw.
I'm likely going to make this the default for PostgreSQL on F
I need to step in and do 2 things:
First, apologize for posting inaccurate test results.
Second, verify that Sean is absolutely correct. FreeBSD 4.8 was accessing
the drives in PIO mode, which is significantly lousier than DMA, which
RedHat was able to use. As a result, the tests are unreasonab
> What it still leaves quite open is just what happens when the OS has
> more than one disk drive or CPU to play with. It's not clear what
> happens in such cases, whether FreeBSD would catch up, or be "left
> further in the dust." The traditional "propaganda" has been that
> there are all sorts
http://www.potentialtech.com/wmoran/postgresql.php
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
Adding my voice to the many, thanks for sharing your results Bill. Very
instructive.
--
Best,
Al Hulaton| Sr. Account Engineer | Command Prompt, Inc.
503.222.2783 | [EMAIL
2003-08-28 ragyogó napján Ludek Finstrle ezt üzente:
> > Intelligent feedback is welcome.
> >
> > http://www.potentialtech.com/wmoran/postgresql.php
>
> Good work. But I can't find information about xfs. Do you plan to add
> this one FS in test?
http://mail.sth.sze.hu/~hsz/sql/
--
Tomka Gerge
2003-08-28 ragyogó napján Christopher Browne ezt üzente:
> A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] ("Balazs Wellisch")
> wrote:
> > Very interesting results. I'd like to command you on your honesty.
> > Having started out with the intentions of proving that FreeBSD is faster
Couple of questions:
What was the postgresql.conf configuration used? Default?
How many threads of the script ran? Looks like a single user only.
I assume there was nothing else running at the time (cron, sendmail,
etc. were all off?)
Do you know whether the machines were disk or I/O bound?
Wa
On Tue, 26 Aug 2003, Bill Moran wrote:
>
> Intelligent feedback is welcome.
>
That's some good work there, Lou. You'll make sgt for that someday.
But I think the next step, before trying out other filesystems and options
would be concurrency. Run a bunch of these beasts together and see what
happ
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] ("Balazs Wellisch")
wrote:
> Very interesting results. I'd like to command you on your honesty.
> Having started out with the intentions of proving that FreeBSD is faster
> than Linux only to find that the opposite is true must not have
> Intelligent feedback is welcome.
>
> http://www.potentialtech.com/wmoran/postgresql.php
Good work. But I can't find information about xfs. Do you plan to add
this one FS in test?
Luf
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Tue, 2003-08-26 at 20:47, Bill Moran wrote:
> Hey all.
>
> I said I was going to do it, and I finally did it.
>
> As with all performance tests/benchmarks, there are probably dozens or
> more reasons why these results aren't as accurate or wonderful as they
> should be. Take them for what the
On Tue, 2003-08-26 at 20:47, Bill Moran wrote:
> Hey all.
>
> I said I was going to do it, and I finally did it.
>
> As with all performance tests/benchmarks, there are probably dozens or
> more reasons why these results aren't as accurate or wonderful as they
> should be. Take them for what the
On Tue, 26 Aug 2003, Bill Moran wrote:
> As with all performance tests/benchmarks, there are probably dozens or
> more reasons why these results aren't as accurate or wonderful as they
> should be. Take them for what they are and hopefully everyone can
> learn a few things from them.
What versio
On 26 Aug 2003 at 21:47, Bill Moran wrote:
> Hey all.
>
> I said I was going to do it, and I finally did it.
>
> As with all performance tests/benchmarks, there are probably dozens or
> more reasons why these results aren't as accurate or wonderful as they
> should be. Take them for what they a
e the integrity of your tests.
Thanks for all the work.
Balazs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill Moran
Sent: Tuesday, August 26, 2003 6:48 PM
To: [EMAIL PROTECTED]
Subject: [PERFORM] The results of my PostgreSQL/filesystem performance
Hey all.
I said I was going to do it, and I finally did it.
As with all performance tests/benchmarks, there are probably dozens or
more reasons why these results aren't as accurate or wonderful as they
should be. Take them for what they are and hopefully everyone can
learn a few things from them
26 matches
Mail list logo
