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
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 PostgreSQL on various platforms, with
PostgreSQL winning!
--
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 :
David Griffiths wrote:
This is a timely thread for myself, as I'm in the middle of testing
both databases as an Oracle replacement.
As of this moment, I know more about MySQL (tuning, setup, features)
than I do about Postgres. Not because I like MySQL more, but because
1) the MySQL docs are
On Thu, 2003-10-09 at 13:30, David Griffiths wrote:
> I also have to admit a bit of irritation reading this thread; there is a
> fair number of incorrect statements on this thread that, while not
> wrong, definately aren't right:
>
> "Speed depends on the nature of use and the complexity of queri
anyway].
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> scott.marlowe
> Sent: Thursday, October 09, 2003 3:26 PM
> To: Jeff
> Cc: David Griffiths; [EMAIL PROTECTED]
> Subject: Re: [PERFORM] PostgreSQL vs MySQL
>
>
&g
On Thu, 9 Oct 2003, Jeff wrote:
> On Thu, 9 Oct 2003, David Griffiths wrote:
>
> > 1) the MySQL docs are better (sorry - I found them easier to read, and
> > more comprehensive; I had an easier time finding the answers I needed)
>
> Huh. I had the opposite experience. Each to his own.
> I think
On Thu, 9 Oct 2003, David Griffiths wrote:
> 1) the MySQL docs are better (sorry - I found them easier to read, and
> more comprehensive; I had an easier time finding the answers I needed)
Huh. I had the opposite experience. Each to his own.
I think everybody agrees PG needs a better tuning doc (
This is a timely thread for myself, as I'm in the
middle of testing both databases as an Oracle replacement.
As of this moment, I know more about MySQL (tuning,
setup, features) than I do about Postgres. Not because I like MySQL more, but
because
1) the MySQL docs are better (sorry - I fo
On Wed, Oct 08, 2003 at 01:28:53PM -0400, Bruce Momjian wrote:
>
> Agreed. Text added to install docs:
[&c.]
I think this is just right. It tells a user where to find the info
needed, doesn't reproduce it all over the place, and still points out
that this is something you'd better do. Combine
> "JB" == Josh Berkus <[EMAIL PROTECTED]> writes:
JB> Hmmm ... both, I think. The Install Docs should have:
JB> "Here are the top # things you will want to adjust in your PostgreSQL.conf:
JB> 1) Shared_buffers
JB> 2) Sort_mem
JB> 3) effective_cache_size
JB> 4) random_page_cost
JB> 5) Fs
On Wed, 2003-10-08 at 14:05, Josh Berkus wrote:
> Hmmm ... both, I think. The Install Docs should have:
>
> "Here are the top # things you will want to adjust in your PostgreSQL.conf:
> 1) Shared_buffers
> 2) Sort_mem
> 3) effective_cache_size
> 4) random_page_cost
> 5) Fsync
> etc."
> Bar
Totally agree.
---
Josh Berkus wrote:
> Bruce,
>
> > Yes, I think that is a good idea --- now, does it go in the install
> > docs, or in the docs next to each GUC item?
>
> Hmmm ... both, I think. The Install Docs should
Bruce,
> Yes, I think that is a good idea --- now, does it go in the install
> docs, or in the docs next to each GUC item?
Hmmm ... both, I think. The Install Docs should have:
"Here are the top # things you will want to adjust in your PostgreSQL.conf:
1) Shared_buffers
2) Sort_mem
3) effect
Brian Tarbox wrote:
> Oddly enough, the particular application in question will have an extremely
> small user base...perhaps a few simultainous users at most.
>
> As to the testing, I neglected to say early in this thread that my manager
> instructed me _not_ to do further performance testing...s
I think the issue with multiple users is that a car is good for moving a
few people, but it can't move lots of large boxes. A truck can move
large boxes, but it can't move a few people efficiently. PostgreSQL is
more like a truck, while MySQL is more like a car.
As an aside, I think Solaris is s
RFORM] PostgreSQL vs. MySQL
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> I'm actually leaving this list but I can answer this question. Our
results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
Hi Brian, I just wanted
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> I'm actually leaving this list but I can answer this question. Our results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
Hi Brian, I just wanted to add that if you aren't testing
On Mon, 7 Jul 2003, Brian Tarbox wrote:
> Oddly enough, the particular application in question will have an extremely
> small user base...perhaps a few simultainous users at most.
>
> As to the testing, I neglected to say early in this thread that my manager
> instructed me _not_ to do further pe
Brian Tarbox kirjutas R, 04.07.2003 kell 15:27:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
> The results we got was that Postgres was fully 3 times slower than MySql.
For each and every qu
On Friday, July 4, 2003, at 07:07 AM, Brian Tarbox wrote:
We had about 40 tables in the db, with joined queries on about 8-12
tables.
A while ago a tested a moderately complex schema on MySQL, Pg, and
Oracle. I usually heavily normalize schemas and then define views as a
denormalized API, whi
...and on Sat, Jul 05, 2003 at 12:24:18AM +0200, Bjoern Metzdorf used the keyboard:
> >> Afaik, your original posting said postgresql was 3 times slower than
> >> mysql and that you are going to leave this list now. This implied
> >> that you have made your decision between postgresql and mysql,
>
>> Afaik, your original posting said postgresql was 3 times slower than
>> mysql and that you are going to leave this list now. This implied
>> that you have made your decision between postgresql and mysql,
>> taking mysql because it is faster.
>
> Well, that shows what you get for making implicati
>Afaik, your original posting said postgresql was 3 times slower than mysql
>and that you are going to leave this list now. This implied that you have
>made your decision between postgresql and mysql, taking mysql because it is
>faster.
Well, that shows what you get for making implications. The c
> I am about to propose a patch that will cause the default shared_buffers
> to be more realistic, say 1000, on machines where the kernel will allow
> it. Not sure if people will let me get away with applying it
> post-feature-freeze, but if so that would change the terms of this
> debate noticeab
Tom,
> I am about to propose a patch that will cause the default shared_buffers
> to be more realistic, say 1000, on machines where the kernel will allow
> it. Not sure if people will let me get away with applying it
> post-feature-freeze, but if so that would change the terms of this
> debate no
Josh Berkus <[EMAIL PROTECTED]> writes:
>> ---snip---
>> By default, PostgreSQL is configured to run on minimal hardware. As
>> a result, some tuning of your installation will be necessary before
>> using it for anything other than extremely small databases. At the
>> very least, it will probably
People:
> I think I did indeed speak too soon, as the criticism is a fair one:
> nowhere in the installation instructions or the "getting started"
> docs does it say that you really ought to do some tuning once you
> have the system installed. Can I suggest for the time being that
> something alo
On Fri, Jul 04, 2003 at 08:07:18PM +0200, Arjen van der Meijden wrote:
> > Andrew Sullivan wrote:
> > results under production conditions, and not bother to read
> > even the basic "quickstart"-type stuff that is kicking
> > around.
> Then please point out where it sais, in the documentation, tha
Why is such a simple list of questions not somewhere in the
documentation? :(
Of course a few of your questions are relatively case-dependent, but the
others are very general. Such information should be in the documentation
and easy to access :)
Regards,
Arjen
> Stephan Szabo wrote a nice list
> Andrew Sullivan wrote:
> I cannot, for the life of me, understand how anyone can
> install some software which is supposed to provide meaningful
> results under production conditions, and not bother to read
> even the basic "quickstart"-type stuff that is kicking
> around.
Then please point
Brian,
Howdy! I'm Josh Berkus, I'm also on the Core Team for PostgreSQL, and I
wanted to give some closure on your issue before you quit with a bad taste in
your mouth.
Your posting hit a sore point in the collective PostgreSQL community, so you
got a strong reaction from several people on th
On Fri, Jul 04, 2003 at 12:10:46PM -0400, Brian Tarbox wrote:
> I am not allowed to share schemas...sorry but thats what the contract says.
> The queries represent code, thus intellectual property, thus I can't post
> them.
If you ask for help, but say, "I can't tell you anything," no-one
will be
On Fri, 4 Jul 2003, Brian Tarbox wrote:
> > I don't think Brian has any interest in being helped.
> >I suspect he'd made up his mind already.
>
>
> With all due respect Tom, I don't think I'm the one demonstrating a closed
> mind.
> Rather than trying to figure out whats going on in my head, how
ren't running
as fast as they would like. This is pathetic!!
Kevin
- Original Message -
From: "Bjoern Metzdorf" <[EMAIL PROTECTED]>
To: "Postgresql Performance" <[EMAIL PROTECTED]>
Sent: Friday, July 04, 2003 11:22 AM
Subject: Re: [PERFORM] PostgreSQL vs.
> I'm not saying (and never did say) that postgres could not be fast.
> All I ever said was that with the same minimal effort applied to both
> DBs, postgres was slower.
Afaik, your original posting said postgresql was 3 times slower than mysql
and that you are going to leave this list now. This i
> I don't think Brian has any interest in being helped.
>I suspect he'd made up his mind already.
With all due respect Tom, I don't think I'm the one demonstrating a closed
mind.
Rather than trying to figure out whats going on in my head, how about
figuring out whats going on in my database? :-)
t;[EMAIL PROTECTED]>
Sent: Friday, July 04, 2003 10:28 AM
Subject: Re: [PERFORM] PostgreSQL vs. MySQL
> On Friday 04 July 2003 20:56, Andrew Sullivan wrote:
> > On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> > > I see this as a major problem. How many
On Friday 04 July 2003 20:56, Andrew Sullivan wrote:
> On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> > I see this as a major problem. How many people run postgres, decide it's
> > too slow and give up without digging into the documentation or coming to
> > this group? This see
On Fri, Jul 04, 2003 at 04:35:03PM +0200, Michael Mattox wrote:
> I see this as a major problem. How many people run postgres, decide it's
> too slow and give up without digging into the documentation or coming to
> this group? This seems to be pretty common. Even worst, they tell 10
> others h
On Friday 04 July 2003 20:36, Rod Taylor wrote:
> > 2. Postgresql uses shared memory being process based architecture. Mysql
> > uses process memory being threaded application. It does not need kernel
> > settings to work and usually works best it can.
>
> MySQL has other issues with the kernel du
> 2. Postgresql uses shared memory being process based architecture. Mysql uses
> process memory being threaded application. It does not need kernel settings to
> work and usually works best it can.
MySQL has other issues with the kernel due to their threading choice
such as memory limits per
hi,
At 20:19 04.07.2003 +0530, Shridhar Daithankar wrote:
[...]
On a positive note, me and Josh are finishing a bare bone performance article
where will be this article published?
that would answer lot of your questions. I am counting on you to provide
valuable feedback. I expect it out tomorrow
On 4 Jul 2003 at 16:35, Michael Mattox wrote:
> I see this as a major problem. How many people run postgres, decide it's
> too slow and give up without digging into the documentation or coming to
> this group? This seems to be pretty common. Even worst, they tell 10
> others how slow Postgres i
"Brian Tarbox" <[EMAIL PROTECTED]> writes:
> I'm not permitted to post the actual tables as per company policy.
Nobody wants to see your data, only the table schemas and queries. If
you feel that even that contains some sensitive information, just rename
the table and field names to something mea
> This appears to be a "yes" answer to my question above. Out of the
> box, PostgreSQL is set up to be able to run on a 1992-vintage SGI
> Indy with 8 M of RAM (ok, I may be exaggerating, but only by a bit);
> it is not tuned for performance. Running without even tweaking the
> shared buffers is
> Please understand the limits of how much information a consultant can submit
> to an open list like this about a client's confidential information. I've
> answered every question I _can_ answer and when I get hostility in response
> all I can do is sigh and move on.
Is there any chance you coul
On Fri, Jul 04, 2003 at 10:07:46AM -0400, Brian Tarbox wrote:
> 512 mb memory, latest production versions of each database. By vanilla
> RedHat I mean that I installed RH on a clean system, said install everything
> and did no customization of RH settings.
Does that include no customization of th
Rod Taylor <[EMAIL PROTECTED]> writes:
>> It was bit too vague to be a comfortable DB tuning problem.
> Completely too little information, and it stopped with Tom asking for
> additional information.
There was something awfully fishy about that. Brian was saying that he
got a seqscan plan out of
On 4 Jul 2003 at 10:07, Brian Tarbox wrote:
> Ok, I'll give more data :-)
>
> Under both MySql and Postgres the tests were run on a variety of systems,
> all with similar results. My own personal testing was done on a P4 2.4Mhz,
> 512 mb memory, latest production versions of each database. By v
ED]
[mailto:[EMAIL PROTECTED] Behalf Of Shridhar
Daithankar
Sent: Friday, July 04, 2003 8:54 AM
To: [EMAIL PROTECTED]
Subject: Re: [PERFORM] PostgreSQL vs. MySQL
On Friday 04 July 2003 17:57, Brian Tarbox wrote:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major o
"Brian Tarbox" <[EMAIL PROTECTED]> writes:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a fair bit looking for answers and tried all
On Fri, 2003-07-04 at 09:20, Shridhar Daithankar wrote:
> On 4 Jul 2003 at 9:11, Rod Taylor wrote:
>
> > > Unless you provide these, it's difficult to help..
> >
> > http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
>
> Well, even in that thread there wasn't enough informatio
On 4 Jul 2003 at 9:11, Rod Taylor wrote:
> > Unless you provide these, it's difficult to help..
>
> http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
Well, even in that thread there wasn't enough information I asked for in other
mail. It was bit too vague to be a comfortable
> Unless you provide these, it's difficult to help..
http://archives.postgresql.org/pgsql-performance/2003-05/msg00299.php
Note the thread with Tom and Brian.
signature.asc
Description: This is a digitally signed message part
On Friday 04 July 2003 17:57, Brian Tarbox wrote:
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this
On Friday 04 July 2003 18:16, Michael Mattox wrote:
> > I'm actually leaving this list but I can answer this question.
> > Our results
> > were with a single user and we were running Inodb. We were running on
> > RedHat 8.0 / 9.0 with vanilla linux settings.
>
> That's funny, you make a statement
> I'm actually leaving this list but I can answer this question.
> Our results
> were with a single user and we were running Inodb. We were running on
> RedHat 8.0 / 9.0 with vanilla linux settings.
That's funny, you make a statement that Postgres was 3 times slower than
MySQL and then you prompt
ly 04, 2003 8:36 AM
To: Brian Tarbox; Rafal Kedziorski; [EMAIL PROTECTED]
Subject: RE: [PERFORM] PostgreSQL vs. MySQL
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The result
> I recently took a system from MySQL to Postgres. Same HW, SW, same data.
> The major operations where moderately complex queries (joins on 8 tables).
>
> The results we got was that Postgres was fully 3 times slower than MySql.
> We were on this list a fair bit looking for answers and tried all
standard answers. It was still much much much slower.
Brian Tarbox
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rafal
Kedziorski
Sent: Friday, July 04, 2003 6:03 AM
To: [EMAIL PROTECTED]
Subject: [PERFORM] PostgreSQL vs. MySQL
Hi,
has anybody tested
On Friday 04 Jul 2003 11:03 am, Rafal Kedziorski wrote:
> Hi,
>
> has anybody tested PostgreSQL 7.3.x tables agains MySQL 4.0.12/13 with
> InnoDB?
Lots of people probably. The big problem is that unless the tester's setup
matches your intended usage the results are of little worth.
For the tests
PostgreSQL (as being a really advanced RDBMS),
generally requires some tuning in order to get
the best performance.
Your best bet is to try both.
Also check to see IF mysql has
-Referential integrity
-subselects
-transactions
-(other usefull features like arrays,user defined types,etc..)
(its pr
Hi,
has anybody tested PostgreSQL 7.3.x tables agains MySQL 4.0.12/13 with InnoDB?
Regards,
Rafal
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
82 matches
Mail list logo
