Re: [HACKERS] What can we learn from MySQL?
On Mon, Apr 26, 2004 at 04:41:35PM -0400, Bruce Momjian wrote: Jean-Michel POURE wrote: [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Dear Bruce, Taking the example of pgAdmin III, which reached nearly one million hits in December (http://www.pgadmin.org/stats/webalizer), nothing seems impossible for PostgreSQL. Why not create an all-in-one bundle offering PostgreSQL, Apache, Php and PhpPgAdmin for Win32 and ... mass-release it. There is no need to create a complete installer. There could be a single installer executing other installers (like it is sometimes the case in the Win32 world). So that installers remain different. A single web page like http://win.postgresql.org; in 40 languages is enough to mass-release PostgreSQL. With an installer and a single web page, PostgreSQL Win32 could quickly reach one million downloads every month. There is no need to look for complicated strategies. Every month, there can be 10% more downloads. In the end, people will even forget the name of MySQL. That seems like a good idea. Agree. The page should be describe basic PostgreSQL features and step-by-step introduction from download to a first user's SELECT ... FROM. Do you expect translate PostgreSQL-win installer to foreign languages? Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] What can we learn from MySQL?
I'm certain you guys could do a far better installer than the one Oracle has, which is very, very fragile. There's all kinds of wonkiness to try and get it to work on a non-supported linux distro (gentoo in my case), and from talking to people who've dealt with it on redhat it's no better. Also, if possible, I think an installer that plays nice with package management systems would be important. Many users want to use their OS's package system to handle install and upgrade rather than some other installer. On Sat, Apr 24, 2004 at 12:10:01PM -0500, Bruno Wolff III wrote: On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Member: Triangle Fraternity, Sports Car Club of America Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
Jean-Michel POURE wrote: [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Dear Bruce, Taking the example of pgAdmin III, which reached nearly one million hits in December (http://www.pgadmin.org/stats/webalizer), nothing seems impossible for PostgreSQL. Why not create an all-in-one bundle offering PostgreSQL, Apache, Php and PhpPgAdmin for Win32 and ... mass-release it. There is no need to create a complete installer. There could be a single installer executing other installers (like it is sometimes the case in the Win32 world). So that installers remain different. A single web page like http://win.postgresql.org; in 40 languages is enough to mass-release PostgreSQL. With an installer and a single web page, PostgreSQL Win32 could quickly reach one million downloads every month. There is no need to look for complicated strategies. Every month, there can be 10% more downloads. In the end, people will even forget the name of MySQL. That seems like a good idea. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What can we learn from MySQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Dear Bruce, Taking the example of pgAdmin III, which reached nearly one million hits in December (http://www.pgadmin.org/stats/webalizer), nothing seems impossible for PostgreSQL. Why not create an all-in-one bundle offering PostgreSQL, Apache, Php and PhpPgAdmin for Win32 and ... mass-release it. There is no need to create a complete installer. There could be a single installer executing other installers (like it is sometimes the case in the Win32 world). So that installers remain different. A single web page like http://win.postgresql.org; in 40 languages is enough to mass-release PostgreSQL. With an installer and a single web page, PostgreSQL Win32 could quickly reach one million downloads every month. There is no need to look for complicated strategies. Every month, there can be 10% more downloads. In the end, people will even forget the name of MySQL. Cheers, Jean-Michel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjW11extoHHj2YFMRAggVAJ0e/W4D/tnm/AtMK0nbjfDROtv/fwCfQ/eC KAnaz5T3PCceVlVS6zirsqg= =N1NM -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
I think that when considering install, it is very important, if not critical, that we all understand who is doing the install. Certainly if it is a person much like us, meaning people on the hackers/development list, we can all handle more terse installs. Personally, I like the freedom of choices, and not having a result of hundreds of megs that I know are not required. On the other hand, we are really a minority. The masses certainly like simple installs, regardless of just how many megs are used, needed or not. If the masses really cared, then Microsoft would be in trouble. But, as we can see in the market place, they don't. In fact, most people think more is better. Somehow they think 2 CDROMs is better than 1 CDROM. So, if it takes an extra 200 meg to make a glitsy install with little videos expounding on how great Postgresql is, then for that user, it will make all of the difference. We need to remember who the audience is. We cannot gain mass market share otherwise. My 2 cents, won't buy coffee, Jordan Henderson --- Bruno Wolff III [EMAIL PROTECTED] wrote: On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. MySQL was my first introduction to SQL databases (I had dabbled with Clipper and Foxpro years earlier, but only for a couple of months and had forgotten most of it by then). So practically all I knew about SQL and RDBMS I got from the MySQL manual. IIRC, MySQL has a chapter for beginners, on how to create your first database and tables, how to insert a record, etc. I see that the Pg manual already has that. Good. The problem is that, since MySQL was my only SQL database I knew for a long time, I didn't know that an RDBMS can be [much] more than what MySQL was/is. I could only do simple SELECTs (no JOINs, let alone subselect since MySQL doesn't support it) but found it sufficient, since I did most of the hard work from Perl/PHP (for example, doing an adjacency tree query by several SELECTs and combining the results myself from the client side). I didn't know squat about stored procedures or triggers or check constraints. I had no idea what a foreign key is -- and when MySQL manual says it's not necessary, slow, and evil, I believed it. I never bothered checking out other databases until I started reading more about transactions, reliability, Date/Codd, and other more theoretical stuffs. Only then I started trying out Interbase, Firebird, SAPDB, DB2, Oracle, and later Pg. So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. So perhaps the direction of advocacy should be towards increasing that awareness? -- dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: Here is a blog about a recent MySQL conference with title, Why MySQL Grew So Fast: http://www.oreillynet.com/pub/wlg/4715 and a a Slashdot discussion about it: http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198 My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we marketing ourselves properly? o Are we focused enough on ease-of-use issues? o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) o Are our priorities too technically driven? Do we care enough about interoperability? When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. To be fair, I got a fair amount of legitimate problems with MIGRATING to standard compliency. I find these issues legitimate, though solveable. Getting a we prefer lowercase to the standard, however, means to me that even if I write a patch to start migration, I'm not likely to get it in. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we focused enough on ease-of-use issues? There are two issues here : ease-of-use for admin and basic users. I recognize my focus on the later as someone using pg as a teaching tool. Having a correct SQL implementation, referential integrity and transactions is an important issue when explaining DB concepts. That's why I could not have used mysql. Having some help/hint/advices/caveat provided for basic users would help. But some of the change I submitted require a lot of changes, especially in the parser, hence are rejected. I also submit patch to try to fix some surprises (there is != but not ==, non-user tables are in stat_.._user_tables viewa...) I had while using pg. My agenda is quite hard to get thru the hacker/patch lists. Maybe because the patches I sent are not really good enough, but also because it is not a real focus of postgres developers. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. - very small shared_buffers setting (16 the minimum thanks to FreeBSD default installation...). With mysql, you don't need to vacuum analyze, and I think the memory management maybe more or less automatic. I think that the default configuration should have some automagic features so that reasonnable values are chosen depending on the available resources, which would allow basic users not to care about it. memory_management = auto/manual... You also need to have a basic standalone binary port to windows. I wish I could allow simply my students to use pg on their home computers. Well, it does not work that simply, you need cygwin at the time, and I haven't seen the windows binary available for download from the pg download page. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) free and serious. o Are our priorities too technically driven? Not bad if other agendas can also get through. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote: So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. Agree. People don't know that an RDBMS can be more better. A lot of users think speed is the most important thing. And they check the performance of SQL server by time mysql -e SELECT... but they don't know something about concurrency or locking. BTW, is the current MySQL target (replication, transactions, ..etc) what typical MySQL users expect? I think they will lost users who love classic, fast and simple MySQL. The trade with advanced SQL servers is pretty full. I don't understand why MySQL developers want to leave their current possition and want to fight with PostgreSQL, Oracle, DB2 .. etc. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. that even if I write a patch to start migration, I'm not likely to get it in. Just changing to uppercase would break old code so such a patch should not just be commited. But would people stop a patch that is backward compatible (in the worst case a setting during initdb)? I'm not so sure they will. -- /Dennis Björklund ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
Karel Zak wrote: On Fri, Apr 23, 2004 at 01:05:21PM +0700, David Garamond wrote: So in my opinion, as long as the general awareness about RDBMS (on what tasks/responsibilities it should do, what features it generally has to have, etc) is low, people will be looking at MySQL as good enough and will not be motivated to look around for something better. As a comparison, I'm always amazed by people who use Windows 95/98/Me. They find it normal/good enough that the system crashes every now and then, has to be rebooted every few hours (or every time they install something). They don't know of anything better. Agree. People don't know that an RDBMS can be more better. A lot of users think speed is the most important thing. And they check the performance of SQL server by time mysql -e SELECT... but they don't know something about concurrency or locking. Even worse: They benchmark SELECT 1+1 one million times. The performance of SELECT 1+1 has NOTHING to do with the REAL performance of a database. Has anybody seen the benchmarks on MySQL??? They have benchmarked CREATE TABLE and so forth. This is the most useless thing I have ever seen. It is so annoying _ I had to post it ;). Regards, Hans BTW, is the current MySQL target (replication, transactions, ..etc) what typical MySQL users expect? I think they will lost users who love classic, fast and simple MySQL. The trade with advanced SQL servers is pretty full. I don't understand why MySQL developers want to leave their current possition and want to fight with PostgreSQL, Oracle, DB2 .. etc. Karel -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/2952/30706 or +43/664/233 90 75 www.cybertec.at, www.postgresql.at, kernel.cybertec.at ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
Dennis Bjorklund [EMAIL PROTECTED] writes: On Fri, 23 Apr 2004, Shachar Shemesh wrote: When I ask about non-standard complience of Pg (turning unquoted identifiers to lowercase instead of uppercase, violating the SQL standard, and requring an expensive rewrite of clients), and I get the answer uppercase is ugly, I think something is wrong. I would love if someone fixed pg so that one can get the standard behaviour. It would however have to be a setting that can be changed so we are still backward compatible. Yes. There have been repeated discussions about how to do this, but no one's come up with a solution that seems workable. See the archives if you care. For the foreseeable future, backwards compatibility is going to trump standards compliance on this point. That doesn't mean we don't care about compliance; it does mean that it is not the *only* goal. I find it a bit odd to be debating this point in this thread, seeing that one of the big lessons I draw from MySQL is standards compliance does not matter... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] What can we learn from MySQL?
There are two issues here : ease-of-use for admin and basic users. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. My goal is to have pg_autovacuum integrated into the backend for 7.5. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Matthew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] What can we learn from MySQL?
Dear Matthew, My goal is to have pg_autovacuum integrated into the backend for 7.5. I know about that, and that would be a good thing. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Yes. I really thing that it should be on by default, because those who will need it more than others are those who will not know about tuning configuration parameters. As I understand the requirements from pg_autovacuum, it means that some statistics will have to be on by default as well. Good luck;-) -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] What can we learn from MySQL?
Bruce Momjian wrote: My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. MySQL became popular at my university when the students discovered they could install it on their personal computers. Just the exposure for personal development and trial is enough to win a following. Win32 installations are a big deal. With win32 machines outnumbering *nix operating systems by more than 10 to 1 (more on personal computers), the unix only restriction reduced the number of possible people testing and developing with it by at least that amount. Most developers I know work primarily on Windows workstations and asking for a machine to run Postgresql on unix is just not practical. With the win32 port, they can run it on their computers and at least test or evaluate their projects. I and a number of my friends are exceptionally please at the progress of the win32 port. Thank you! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
My goal is to have pg_autovacuum integrated into the backend for 7.5. I know about that, and that would be a good thing. I hope so! I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Yes. I really thing that it should be on by default, because those who will need it more than others are those who will not know about tuning configuration parameters. As I understand the requirements from pg_autovacuum, it means that some statistics will have to be on by default as well. I think it's premature to have this conversation. I need to get something done / working before we dicuss optimal configuration. That said, I also agree that if it's good enough, it should be on by default. Good luck;-) Thanks, I'll need it Matthew ps: I'm hoping to have time to work on this starting in May. I haven't really done any development on pg_autovacuum beyond bug fixing what is already in CVS, so If someone out there wants to work on it, don't wait for me, I won't be offended :-) I just want to see it up and running. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
Matthew T. O'Connor wrote: I think it's premature to have this conversation. I need to get something done / working before we dicuss optimal configuration. That said, I also agree that if it's good enough, it should be on by default. Good luck;-) Thanks, I'll need it Matthew ps: I'm hoping to have time to work on this starting in May. I haven't really done any development on pg_autovacuum beyond bug fixing what is already in CVS, so If someone out there wants to work on it, don't wait for me, I won't be offended :-) I just want to see it up and running. I am around for assistance. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. Dave On Fri, 2004-04-23 at 08:58, Matthew T. O'Connor wrote: There are two issues here : ease-of-use for admin and basic users. On for former point, admin ease-of-use, A little story a few month ago. I succeeded in advising production people here to switch some applications from a mysql database, which was working perfectly, to a postgres database. A few weeks later, the performances were desastrous. 30 seconds to get an answer to a simple select on a 1500 entries tables. After investigation, the problems were: - no vacuum, although there were daily DELETE FROM tables; to empty all the data and reload from another source. - no analyze, because the admin did not know about it. My goal is to have pg_autovacuum integrated into the backend for 7.5. I don't know if it will default to being turned on or off, I'm sure that will be a discussion, but if it is defaulted to on, then this whole problem of having to train newbies about vacuum should just go away. Matthew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html !DSPAM:40892fd393131228097780! -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. -- D'Arcy J.M. Cain [EMAIL PROTECTED]|vex}.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(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: [HACKERS] What can we learn from MySQL?
Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. No the current implementation doesn't, but such a feature is in the works (planned anyway). What I was envisioning is the ability to set two different sets of thresholds (peak / off peak). If you demand zero vacuuming during peak times, you could set that threshold to -1, or some such setting. FYI I wouldn't remcommend defaulting pg_autovacuum to on until it does this, and a few more things that are also planned (see the archives). Matthew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Right, there has been some talk about taking the system load into account, but no action yet. One comment I failed to make in my last email was that there should be less need to explictly disallow vacuum during peak periods since vacuum will only be occuring on specific tables when needed, which will effect the server for a much smaller period of time than a general vacuum command that touches all the tables. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
D'Arcy J.M. Cain wrote: On Fri, 23 Apr 2004 11:07:20 -0400 Dave Cramer [EMAIL PROTECTED] wrote: Does the current implementation of pg_autovacuum have a way of setting windows where it is allowed to vacuum? Many large 24/7 will only allow vacuumming at certain times of the day. It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Or the number of connected backends, or both? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] What can we learn from MySQL?
On Fri, 23 Apr 2004 13:08:30 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: D'Arcy J.M. Cain wrote: It seems to me that the point of pg_autovacuum would be to run 24/7 so that there is never big hit on the system. Perhaps it could be designed to throttle itself based on current system usage though. Or the number of connected backends, or both? I am sure that there are lots of ways to guage. Not sure which is best but I am sure that the smart people here will figure it out. The important thing, I think, is to let the engine make the decision dynamically. Personally I don't have a quiet time per se but there are random quiet periods. Something that jumps into the fray at those points would be really nicwe. -- D'Arcy J.M. Cain [EMAIL PROTECTED]|vex}.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] What can we learn from MySQL?
On Thu, 2004-04-22 at 21:09, Bruce Momjian wrote: Questions I have are: o Are we marketing ourselves properly? It is perhaps less a matter of marketing and more a matter of word-of-mouth mind share. I don't see much evidence of effective direct marketing, but I've noticed a huge growth in mind share among the technical crowd over the last few years, which appears to be an outgrowth of technical reputation. o Are we focused enough on ease-of-use issues? No, and I think this is THE biggest impediment to popularity. The real question should actually be ease-of-use for who?. I had little difficulty adapting to Postgres because I have tons of database experience and so I knew what I was looking for in the technical documentation, which is quite good for an experienced person. But I have noticed that most people who have a much more limited experience with RDBMS administration have a hard time getting started because the use curve is pretty steep. Ease of use isn't an issue for people like me -- I find it very easy -- but is a significant hurdle for most everyone else e.g. casual developers. Some specific recommendations on this: - Make a standard GUI admin tool a prominent part of the standard Postgres distribution, something along the lines of pgAdmin. I don't use it, but a lot of other people need it. For casual database developers, this will greatly enhance apparent ease of use. - Pick a procedural language (plpgsql would seem like the obvious choice) and make it a standard part of a Postgres installation. A standard procedural language should be an out-of-the-box feature that just works. Standard connection drivers (JDBC, ODBC, etc) should also be installed by default and visible to the user. Doing a standard installation of Postgres for most people requires collecting a half dozen bits and pieces that would be installed by default or as install-time options for many databases. - Make it much easier for the relatively clueless to install options in their database. Having an official menu of popular add-on modules (e.g. some of the contrib stuff), and an easy way to automagically enable these capabilities, will serve to educate users that these features exist and encourage their use. I find that most new Postgres users aren't aware that any of these things exist outside of whatever was included with a vanilla install. - Expanded documentation and well-indexed how-tos, both for the database itself and for building applications using the database, for people who are clueless about the technical details of Postgres internals would be helpful. The standard documentation tree is a bit too reference-y for less experienced people, and makes certain contextual assumptions that I find many less experienced trying to navigate it don't have. There is a gap in the documentation between total n00b and experienced DBA that makes it hard to transition that gap. Postgres actually has very good ease-of-use for experienced DBAs, which is something that it definitely gets right. And comparing a Postgres installation to an Oracle installation is like night and day. The problem is that there is no easy bootstrap path for people who aren't so experienced with database administration and maintenance in general. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) Postgres should be positioned as an effective alternative to Oracle, and the focus should be on the enterprise database space. Postgres has some significant leverage points in the enterprise database space, even today, and as it becomes more feature-complete it will increasingly become a compelling choice within this space. Comparing Postgres to MySQL is a mistake IMO, as it leads people to assume that they are roughly equivalent products. I actually read a very recent Gartner Group report comparing Postgres and MySQL a couple months ago that basically said that Postgres and MySQL are equivalent products, but MySQL is easier to use. And their reasoning basically cited the myriad of MySQL versus Postgres comparisons on the 'net. The suits who did the research had difficulty evaluating the technical merits and so they based relative equivalence on the fact that they were constantly compared to each other in the same light. From a marketing standpoint, I would focus all my effort on comparisons to commercial enterprise DB engines like Oracle and ignore MySQL. This will define Postgres as a part of the enterprise market and remove it from the same market space that MySQL occupies. o Are our priorities too technically driven? No. The greatest strength of Postgres, marketing-wise, are technical and is what drives its growth today. I think most of the ease-of-use issues are in the packaging of the larger Postgres product and mid-level developer documentation, both of which seem to be eminently
Re: [HACKERS] What can we learn from MySQL?
J. Andrew Rogers wrote: No. The greatest strength of Postgres, marketing-wise, are technical and is what drives its growth today. I think most of the ease-of-use issues are in the packaging of the larger Postgres product and mid-level developer documentation, both of which seem to be eminently solvable problems. I think improved default product packaging would remove 80% plus, up to this point AFAIK the postgresql docs have not been quoted here: http://www.dbdebunk.com which speaks volumes ;) Merlin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What can we learn from MySQL?
I have been thinking about this subject for a LONG time, and I hope I have something to contribute. My question is, What can we learn from MySQL? I don't know there is anything, but I think it makes sense to ask the question. Questions I have are: o Are we marketing ourselves properly? I would say this is a clear 'NO!' When ever I read about open-source being used anywhere, I always read MySQL. They are *very* good at this. o Are we focused enough on ease-of-use issues? Again, NO! To often you guys settle for a work-around rather than a feature. You are satisfied that symlinks will do the job. When someone says they want a feature, you say, no - use a symlink. Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. I know a bit about this, as I made a PostgreSQL for Windows (It was 7.3.x) CD a while back. I had to do a lot of work on the postgresql configuration, database initialization, and create a demo database. It used a minimal cygwin environment, a Windows based installer, and some custom function libraries. I tried to submit the configuration patch and all I got was argument about using symlinks or how it wasn't needed. The thing that kind of bugs me about this O/S project is that you guys are a bit nit-picking about how someone uses it. I believe in the UNIX phylosophy: capability not policy, flexability, etc. You guys seem to need an absolute reason to include something, rather than a good reason to exclude something. A lot of open source developers are turned off by this sort of attitude. o How do we position ourselves against a database that some say is good enough (MySQL), and another one that some say is too much (Oracle) My argument against this is that MySQL is no less complicated than PostgreSQL. PostgreSQL, in production is faster than MySQL, even though MySQL may be marginally faster on some simple queries. The system resource usage of both systems is very similar. PostgreSQL, however, boasts a lot of standard features that make using it much easier. o Are our priorities too technically driven? For the most part, you guys do a great, no .. fantastic, job at the technical details of the database. Even though I get frustrated, I know it is a great system. You *should* be technically driven. If you want to blow the competition out of the water, you need a non-forked Windows version of the database. You need a Java (or some other portable environment) installer. You need to get out of the hand-administered mentality of using symlinks and system level constructs. One should be able to install the software, bring up a nice configuration program which runs you through a few questions, and be done. This same configuration program should be able to help maintain and control an the installation. On Windows, have a service monitor program that starts and stops the server, on UNIX, have it able to start/stop via init.d. Everything else is expert level. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, - -- Bruce Momjian [EMAIL PROTECTED] wrote: o Are we marketing ourselves properly? while talking about MySQL, there is the myth, that MySQL is fast; and that because MyISAM has no transactions, that it is faster. That is in most cases not true! And for all real live scenarios I know and I tested, Postgres was faster. An example: a critical calculation in one of my online projects needs with MySQL (MyISAM Table Type) about 2.7 to 2.8 seconds (group by on 50 rows for some realtime statistics). But on this time, the complete table is write locked (because MyISAM) :-( With InnoDB the same needs at least 15 to 20 seconds, but other users can insert/update. With PostgreSQL (7.4) it took 1.9 to 2 seconds. Parallel inserts/updates no problem. The only reason why I changed the whole stuff to Postgres yet is, that there are a lot of problems with MySQL special features (see the Gotchas: http://sql-info.de/mysql/gotchas.html) Other example: Some days ago I had a talk with my project leader; I said, that for a new application we should *everything* build with transactions, referential integrity, ... -- his answer: I want to have a fast application. AAARRGH! ;-( So, perhaps it might be a good idea to create a page with feature- and performance comparison. I planed to create an independant and RDBMS benchmark suite (as Free Software including the datas for testing), but I'm not sure if this project ever come true ... o Are we focused enough on ease-of-use issues? I'm not sure about the focus; but the result can be better. When installing and using any type of software, I want that this is as easy as possible while it helps me to understand as much of the backgrounds as possible. Whats about the initdb, postgresql.conf and startup scripts? So, It might be good to have a GUI-Tool (!) in the standard package, which makes an initdb with selectable options and helps the user to set the required options in the postgresql.conf. I'm a computer freak since the mod 80s and I can edit config files. But to have a GUI tool with some explaining texts at the buttons etc is much easyer than hacking a textfile. Also the other stuff mentioned in this thread are important: auto vacuum, windows port, better default values etc. Ease-of-use includes for me localisation and documentation in different languages. As you can see, my english is junky -- so reading german documentation is a lot of easyer for me ;-) o Are our priorities too technically driven? AFAIK it is good to have the priorities technically driven -- if nobody forgets the userfriendlyness ;) Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiX/eOndlH63J86wRAjzhAJ0f24+yuOSElI7NmFuChZUH3miWiACdFoH+ OLC0iUn7VP/ZIA30vU8M0tg= =RVWf -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] What can we learn from MySQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, - -- [EMAIL PROTECTED] wrote: I would say this is a clear 'NO!' When ever I read about open-source being used anywhere, I always read MySQL. They are *very* good at this. yes! Some days ago, there was a news in the Heise Newsticker (most important IT news in germany), about MySQL clustering. http://www.heise.de/newsticker/meldung/46511 4*2 processors with 10 replicated transactions per second was the main statement. I'm sure, that this is the typical MySQL blabla: no transactions, but select statements ... http://www.heise.de/newsticker/foren/go.shtml?read=1msg_id=5487088forum_id =55321 I'm not sure, if iot is a good idea to go down with the niveau to such lies. o Are we focused enough on ease-of-use issues? Again, NO! To often you guys settle for a work-around rather than a feature. You are satisfied that symlinks will do the job. When someone says they want a feature, you say, no - use a symlink. [...] yes, you are right! One additional thing: when updating from 7.x to 7.y, a new initdb is needed. This means: If I have some GB Data, the RDBMS is some ours down for upgrading. This is really no good situation. There should be a way for converting the storage on the fly: Updating and let postgres do the rest automaically. I guess this is not really easy; but it is important! Ciao Alvar - -- ** Alvar C.H. Freude -- http://alvar.a-blast.org/ -- http://odem.org/ ** Berufsverbot? http://odem.org/aktuelles/staatsanwalt.de.html ** ODEM.org-Tour: http://tour.odem.org/ ** 5 Jahre Blaster: http://www.a-blast.de/ | http://www.a-blast.de/statistik/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAiYcpOndlH63J86wRAoj7AKCt+SXIV/1UYa7hZlEpA1SrwpctnQCgpypM 2L5aRteQ7btVuBowcclBc28= =POHj -END PGP SIGNATURE- ---(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
