On Fri, 2007-11-16 at 11:06 -0500, Jonah H. Harris wrote:
> On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > I don't know about that. There are times when it is the right plan:
>
> Agreed. IMHO, there's nothing wrong with nested-loop join as long as
> it's being used proper
On Nov 16, 2007 3:36 PM, Josh Trutwin <[EMAIL PROTECTED]> wrote:
> > Agreed. IMHO, there's nothing wrong with nested-loop join as long
> > as it's being used properly.
>
> Can you explain further please? (I'm not disagreeing with you, just
> want to know when nested loops are not used properly -
On Fri, 16 Nov 2007 11:06:11 -0500
"Jonah H. Harris" <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> > I don't know about that. There are times when it is the right
> > plan:
>
> Agreed. IMHO, there's nothing wrong with nested-loop join as long
>
Dimitri wrote:
> Reading this article I'm just happy for them to see progress done on FreeBSD
> :-)
> As well to demonstrate OS parallelism it's not so impressive to see
> 4CPU server results rather 8CPU or 32threaded Niagara... Don't know
> why they did not present similar performance graphs for
On Nov 16, 2007 10:56 AM, Dave Dutcher <[EMAIL PROTECTED]> wrote:
> I don't know about that. There are times when it is the right plan:
Agreed. IMHO, there's nothing wrong with nested-loop join as long as
it's being used properly.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1
> -Original Message-
> From: Ow Mun Heng
> Subject: Re: [PERFORM] PostgreSQL vs MySQL, and FreeBSD
>
> Even for Postgresql, nested loops are still evil and hampers
> performance.
I don't know about that. There are times when it is the right plan:
explai
On Fri, 2007-11-09 at 16:41 +0100, Sebastian Hennebrueder wrote:
> If the queries are complex, this is understable. I had a performance
> review of a Hibernate project (Java Object Relation Mapping) using
> MySQL. ORM produces easily "complex" queries with joins and subqueries.
> MySQL uses neste
On Nov 11, 2007, at 2:17 PM, Joshua D. Drake wrote:
Dimitri wrote:
Seems to me there is more thread model implementation problem on
FreeBSD, and databases just reflecting it... Most of the test I done
on Solaris show the same performance level on the same short READ-
only
queries for MySQL a
Steinar H. Gunderson wrote:
On Sun, Nov 11, 2007 at 08:27:02PM +0100, Dimitri wrote:
As well to demonstrate OS parallelism it's not so impressive to see
4CPU server results rather 8CPU or 32threaded Niagara... Don't know
why they did not present similar performance graphs for these
platform, str
On Sun, Nov 11, 2007 at 08:27:02PM +0100, Dimitri wrote:
> As well to demonstrate OS parallelism it's not so impressive to see
> 4CPU server results rather 8CPU or 32threaded Niagara... Don't know
> why they did not present similar performance graphs for these
> platform, strange no?...
I guess it
Dimitri wrote:
Seems to me there is more thread model implementation problem on
FreeBSD, and databases just reflecting it... Most of the test I done
on Solaris show the same performance level on the same short READ-only
queries for MySQL and PostgreSQL.
And to be honest till the end, thread mode
Seems to me there is more thread model implementation problem on
FreeBSD, and databases just reflecting it... Most of the test I done
on Solaris show the same performance level on the same short READ-only
queries for MySQL and PostgreSQL.
And to be honest till the end, thread model should be far f
Bill Moran wrote:
> On Fri, 9 Nov 2007 11:11:18 -0500 (EST)
> Greg Smith <[EMAIL PROTECTED]> wrote:
>> On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
>>> If the queries are complex, this is understable.
>> The queries used for this comparison are trivial. There's only one table
>> involved and
On Fri, 9 Nov 2007 11:11:18 -0500 (EST)
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
>
> > If the queries are complex, this is understable.
>
> The queries used for this comparison are trivial. There's only one table
> involved and there are no join
On Fri, 9 Nov 2007, Sebastian Hennebrueder wrote:
If the queries are complex, this is understable.
The queries used for this comparison are trivial. There's only one table
involved and there are no joins. It's testing very low-level aspects of
performance.
--
* Greg Smith [EMAIL PROTECTE
On Nov 9, 2007 9:41 AM, Sebastian Hennebrueder <[EMAIL PROTECTED]> wrote:
> If the queries are complex, this is understable. I had a performance
> review of a Hibernate project (Java Object Relation Mapping) using
> MySQL. ORM produces easily "complex" queries with joins and subqueries.
> MySQL use
On Nov 9, 2007, at 6:06 AM, Ivan Voras wrote:
Hi,
I just read this document and thought I should share it with this
list:
http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Among other things (FreeBSD advocacy, mostly :) ), it contains a
direct
comparison between MySQL and Postgr
>
> Among other things (FreeBSD advocacy, mostly :) ), it contains a direct
> comparison between MySQL and PostgreSQL on various platforms, with
> PostgreSQL winning!
>
Hello,
If the queries are complex, this is understable. I had a performance
review of a Hibernate project (Java Object Relati
On Nov 9, 2007 7:06 AM, Ivan Voras <[EMAIL PROTECTED]> wrote:
> I just read this document and thought I should share it with this list:
>
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf
Nice presentation. Thanks for posting it on here.
> Among other things (FreeBSD advocacy, mostly :
19 matches
Mail list logo
