Re: [PERFORM] PostgreSQL vs. MySQL
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 that Postgres was 3 times slower than MySQL and then you promptly leave the list! Just kidding. It'd be interesting to see what happens if you test your system with a hundred users. If it's a webapp you can use JMeter to do this really easily. Hundred users is a later scenario. I am curious about vanilla linux settings What does that mean. Postgresql communmity would always like to help who need it but this thread so far gives me impression that OP isn't willing to provide sufficient information.. Shridhar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] PostgreSQL vs. MySQL
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 information I asked for in other mail. 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. I don't think Brian has any interest in being helped. Many here would be more than happy to do so if the information were to flow. signature.asc Description: This is a digitally signed message part
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 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 the standard answers. It was still much much much slower. I have never found a query in MySQL that was faster than one in PostgreSQL. Chris ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] PostgreSQL vs. MySQL
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 could show us an EXPLAIN ANALYZE output of the poor performing query in question? I'm sorry if Shridhar is upset that I can't validate his favorite db but ad hominin comments aren't helpful. It was me who gave the comment based upon previous threads which requested information that had gone unanswered (not even a response stating such information could not be provided). The database you describe is quite small, so I'm not surprised MySQL does well with it. That said, it isn't normal to experience poor performance with PostgreSQL unless you've stumbled upon a poor spot (IN based sub-queries used to be poor performing, aggregates can be slow, mismatched datatypes, etc.). Output of EXPLAIN ANALYZE of a contrived query representative of the type of work done (that demonstrates the problem) with renamed tables and columns would go a long way to helping us help you. signature.asc Description: This is a digitally signed message part
Re: [PERFORM] PostgreSQL vs. MySQL
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 meaningless. But the kinds of problems I am interested in finding out about require seeing the column datatypes and the form of the queries. The hardware and platform details you gave mean nothing to me (and probably not to anyone else either, given that you were comparing to MySQL on the same platform). I did no tuning of MySql. The only tuning for PG was to vacuum and vacuum analyze. If you didn't at least bump up shared_buffers, you were deliberately skewing the results against Postgres. Surely you can't have been subscribed to pgsql-performance very long without knowing that the default postgresql.conf settings are set up for a toy installation. all I can do is sigh and move on. You're still looking for reasons not to answer our questions, aren't you? Do you actually want to find out what the problem was here? If not, you're wasting our list bandwidth. I'd like to find out, if only so I can try to fix it in future releases, but without useful information I'll just have to write this off as an unsubstantiated report. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PERFORM] PostgreSQL vs. MySQL
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 process, or poor threaded SMP support on some platforms (inability for a single process to use more than one CPU at a time regardless of thread count). Threads aren't an easy way around kernel limitations, which is probably why Apache has gone for a combination of the two -- but of course that adds complexity. signature.asc Description: This is a digitally signed message part
Re: [PERFORM] PostgreSQL vs. MySQL
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 implied that you have made your decision between postgresql and mysql, taking mysql because it is faster. Now you say your testing setup has minimal effort applied. Well, it is not very surprising that mysql is faster in standard configurations. As Shridhar pointed out, postgresql has very conservative default values, so that it starts on nearly every machine. If I was your client and gave you the task to choose a suitable database for my application and you evaluated suitable databases this way, then something is seriously wrong with your work. Regards, Bjoern ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PERFORM] PostgreSQL vs. MySQL
My goodness people!! If you are just going to bash people who are trying to learn PostgreSQL then you have no chance of ever getting new people using it! Cut out this crap and do what this list is meant to do, which is, I'm assuming, helping people figure out why their installations aren'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. MySQL 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 implied that you have made your decision between postgresql and mysql, taking mysql because it is faster. Now you say your testing setup has minimal effort applied. Well, it is not very surprising that mysql is faster in standard configurations. As Shridhar pointed out, postgresql has very conservative default values, so that it starts on nearly every machine. If I was your client and gave you the task to choose a suitable database for my application and you evaluated suitable databases this way, then something is seriously wrong with your work. Regards, Bjoern ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
