I had such great hopes for this thread. "Alas, poor Yorick! I
knew him, Horatio ..."
On Thu, Jul 12, 2007 at 11:00:54AM -0400, Greg Smith wrote:
> On Thu, 12 Jul 2007, Gregory Stark wrote:
>
> >In any case I wouldn't think the use case for a feature like this would
> >actually apply in the
Le mercredi 11 juillet 2007 à 13:37 -0300, André Gomes Lamas Otero a
écrit :
> I don't this so, because DB2 is running on a Sun Sparc T1 processor
> (http://www.sun.com/processors/UltraSPARC-T1/) that's implements much
> more features, like thread level parelelism, than AMD Opteron.
>
> the DB2
On Thu, 12 Jul 2007, Gregory Stark wrote:
In any case I wouldn't think the use case for a feature like this would
actually apply in the case of a benchmark.
I've also seen a tiny setting for commit_delay (like the 10 they used) as
helping improve throughput under a heavy commit load with many
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> Jignesh K. Shah wrote:
>> Can you list others that seemed out of place?
The one which surprised me the most was the commit_delay setting. What results
led you to set that? The common wisdom on this setting is that it doesn't
accomplish its goa
Jignesh K. Shah wrote:
> Can you list others that seemed out of place?
well to me the ones that look most questionable are:
work_mem=100MB - so this benchmark is really low concurrency(which does
not fit with max_connections=1000) and with trivial queries ?
enable_seqscan = off - why ?
effectiv
Can you list others that seemed out of place?
Thanks.
Regards,
Jignesh
Tom Lane wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
Heikki Linnakangas wrote:
May I ask you why you set max_prepared_transactions to 450, while
you're apparently not using prepared transactions, accordin
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> May I ask you why you set max_prepared_transactions to 450, while
>> you're apparently not using prepared transactions, according to this
>> quote:
> Yep.. one of the things that we didn't revert back and got strayed ou
I don't this so, because DB2 is running on a Sun Sparc T1 processor
(http://www.sun.com/processors/UltraSPARC-T1/) that's implements much
more features, like thread level parelelism, than AMD Opteron.
the DB2 installation:
J2EE AppServer HW (SUT hardware)
Hardware Vendor: Sun Microsystems
Heikki Linnakangas wrote:
May I ask you why you set max_prepared_transactions to 450, while
you're apparently not using prepared transactions, according to this
quote:
Recoverable 2-phase transactions were used to coordinate the
interaction between
the database server and JMS server usi
Jignesh K. Shah wrote:
Hello all,
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
More on Josh Berkus's blog:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-fi
Its hard to do direct comparison since that one used a different
commercial application server than the PostgreSQL test.. As we do more
tests with the help of the community, hopefully we can understand where
the CPU cycles are spent and see how to make them more efficient...
Stay tuned!!
-Jig
am I wrong or DB2 9.1 is faster on less powerfull hardware ?
Le lundi 09 juillet 2007 à 11:57 -0400, Jignesh K. Shah a écrit :
> Hello all,
>
> I think this result will be useful for performance discussions of
> postgresql against other databases.
>
> http://www.spec.org/jAppServer2004/results/
Hi,
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
More on Josh Berkus's blog:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-
publishes-first-real-benchmark-17470
On Mon, Jul 09, 2007 at 01:48:44PM -0400, Jignesh K. Shah wrote:
>
> Hi Heikki,
>
> Heikki Linnakangas wrote:
> >
> >That's really exciting news!
> >
> >I'm sure you spent a lot of time tweaking the settings, so let me ask
> >you something topical:
> >
> >How did you end up with the bgwriter set
On 7/9/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
PostgreSQL still beats MySQL ;)
Agreed.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation| fax: 732.331.1301
33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED]
Iselin, New Jersey 08830
Jonah H. Harris wrote:
On 7/9/07, Greg Smith <[EMAIL PROTECTED]> wrote:
There's just enough hardware differences between the two configurations
that it's not quite a fair fight. For example, the MySQL test had 10K
RPM
drives in the database server storage array, while the PostgreSQL one had
1
On 7/9/07, Greg Smith <[EMAIL PROTECTED]> wrote:
There's just enough hardware differences between the two configurations
that it's not quite a fair fight. For example, the MySQL test had 10K RPM
drives in the database server storage array, while the PostgreSQL one had
15K RPM ones. A few other
On Mon, 9 Jul 2007, Joshua D. Drake wrote:
I would note that if you track through the other results that we indeed beat
MySQL ;)
There's just enough hardware differences between the two configurations
that it's not quite a fair fight. For example, the MySQL test had 10K RPM
drives in the da
On Jul 9, 2007, at 1:02 PM, Joshua D. Drake wrote:
It is also the reason that those in the know typically ignore all
benchmarks and do their own testing.
Heresy!
---(end of broadcast)---
TIP 6: explain analyze is your friend
Joshua D. Drake wrote:
> Steinar H. Gunderson wrote:
>> On Mon, Jul 09, 2007 at 11:57:13AM -0400, Jignesh K. Shah wrote:
>>> I think this result will be useful for performance discussions of
>>> postgresql against other databases.
>>>
>>> http://www.spec.org/jAppServer2004/results/res2007q3/
>>
>>
Hi Heikki,
Heikki Linnakangas wrote:
That's really exciting news!
I'm sure you spent a lot of time tweaking the settings, so let me ask
you something topical:
How did you end up with the bgwriter settings you used? Did you
experiment with different values? How much difference did it make?
Steinar H. Gunderson wrote:
On Mon, Jul 09, 2007 at 11:57:13AM -0400, Jignesh K. Shah wrote:
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
Am I right if this is for a T2000 (Niagara)
On Mon, Jul 09, 2007 at 11:57:13AM -0400, Jignesh K. Shah wrote:
> I think this result will be useful for performance discussions of
> postgresql against other databases.
>
> http://www.spec.org/jAppServer2004/results/res2007q3/
Am I right if this is for a T2000 (Niagara) database server? It sure
Jignesh K. Shah wrote:
Hello all,
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
More on Josh Berkus's blog:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-fi
Jonah H. Harris wrote:
On 7/9/07, Jignesh K. Shah <[EMAIL PROTECTED]> wrote:
I think this result will be useful for performance discussions of
postgresql against other databases.
I'm happy to see an industry-standard benchmark result for PostgreSQL.
Great work guys!
I would note that if you
On 7/9/07, Jignesh K. Shah <[EMAIL PROTECTED]> wrote:
I think this result will be useful for performance discussions of
postgresql against other databases.
I'm happy to see an industry-standard benchmark result for PostgreSQL.
Great work guys!
--
Jonah H. Harris, Software Architect | phone: 73
Hello all,
I think this result will be useful for performance discussions of
postgresql against other databases.
http://www.spec.org/jAppServer2004/results/res2007q3/
More on Josh Berkus's blog:
http://blogs.ittoolbox.com/database/soup/archives/postgresql-publishes-first-real-benchmark-17470
27 matches
Mail list logo
