Thread: 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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
I've been sort-of reading this thread off and on, so this may contain duplicate suggestions. I was researching an article I wrote about a comparison between Postgres and MySQL recently (If you want, you can read the article at http://www.devx.com/dbzone/Article/20743/). I noticed some clear differences between the mysql.com website and the Postgres website. 1) Since MySQL AB supports and trains for MySQL, there's loads of training information available on their website. On the other hand, I had a hard time finding training information for Postgres in general. Same goes for support. It's easier to find, but it's still somewhat convoluted, IMO. 2) There doesn't seem to be a clear roadmap on Postgres features. When certian things are expected. There's the TODO list that Bruce maintains, but it only outlines 'near' fixes. MySQL has a nice listing of what to expect in certian future versions. I know it's not a perfect list, but it'd be nice to know when full blown replication will be included in PostgreSQL as an example. On those same lines, there doesn't seem to be anything about the improvements in the minor versions. It seems that in every release (i.e. 7.2,7.3,7.4) there are pretty significant changes, but finding a place that outlines these changes is somewhat difficult. While being somewhat nit-picky on this, it'd also be helpful if someone wasn't completely database literate could understand some of the changes. Who needs transactions, anyways? :) 3) There's the issues of 'advanced database features' in general. Many MySQL applications perform much of their logic in the application level, instead of the database level. They do this because there aren't things like triggers or stored procedures in MySQL. As the saying goes, 'if mohammad won't go to the mountain, bring the mountian to mohammad'. Why not do some simple explainations as to why these things are good, and what they do, and how to use them in real context? 4) As other peole have noted, there's no windows build readily available for Postgres. There may be, but it's difficult to find. If someone's used to running, say, Oracle, and all they have is a windows machine to test something out on, MySQL has compiled binaries ready to go. 5) I believe that this was noted as well somewhere along the line - the other tools, like pgadmin III aren't readily available either. They're excellent tools, and they should be quick to find on the postgres website. 6) Bug tracking. I haven't really looked into how MySQL handles this, but when learning about Postgres, I discovered that the whole development model seemed kind of 'closed', and people on the mailing lists would find bugs repeatedly. Something like Bugzilla would be very helpful in this respect. I've been kind of out of the loop for the past 6 months in this area, so it may have changed since then. 7) The two Postgres books are available online for anyone to read and download. They're there, but, to me, you have to notice them on the sidebar to go to them. They're extremely helpful, and they should be pointed out more. Most of these suggestions aren't really anything to do with the database itself. It's simply a re-organization of some of the information that's already available. As others have mentioned, 'it's about the PR'. Just my $.02 worth. Tim
Hi! Tim Conrad wrote: > I was researching an article I wrote about a comparison between > Postgres and MySQL recently (If you want, you can read the article > at http://www.devx.com/dbzone/Article/20743/). I noticed some clear > differences between the mysql.com website and the Postgres website. Sorry, couldn't resist: may I suggest doing the research *before* writing an article, not *after*? My favourite part of it is: -------- MySQL uses traditional row-level locking. PostgreSQL uses something called Multi Version Concurrency Control (MVCC) by default. MVCC is a little different from row-level locking in that transactions on the database are performed on a snapshot of the data and then serialized. New versions of PostgreSQL support standard row-level locking as an option, but MVCC is the preferred method. -------- > 2) There doesn't seem to be a clear roadmap on Postgres features. > When certian things are expected. There's the TODO list that > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > nice listing of what to expect in certian future versions. I know > it's not a perfect list, but it'd be nice to know when full blown > replication will be included in PostgreSQL as an example. MySQL's roadmap is complete bullshit. Subselects were first promised in 4.0, which was "not that far away" [1] back in 1998! Well, they are in 4.1, which is still alpha in 2004. Of course, some gullible people actually believe this and compare [2] the existing and working implementations with vaporware (MySQL 5.1, anyone?). > On those same lines, there doesn't seem to be anything about the > improvements in the minor versions. It seems that in every > release (i.e. 7.2,7.3,7.4) there are pretty significant changes, > but finding a place that outlines these changes is somewhat > difficult. Have you tried looking in the release notes [3]? [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 [3] http://www.postgresql.org/docs/7.4/interactive/release.html
On Tue, 27 Apr 2004, Tim Conrad wrote: > 2) There doesn't seem to be a clear roadmap on Postgres features. > When certian things are expected. There's the TODO list that > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > nice listing of what to expect in certian future versions. Not possible for us, since we have no "upper management" that dictates what features get added, for when ... > I know > it's not a perfect list, but it'd be nice to know when full blown > replication will be included in PostgreSQL as an example. Never, since there is no such thing as a 'full blown replication', since there is no *one* way to do replication ... > 3) There's the issues of 'advanced database features' in general. > Many MySQL applications perform much of their logic in the > application level, instead of the database level. They do this > because there aren't things like triggers or stored procedures > in MySQL. As the saying goes, 'if mohammad won't go to the > mountain, bring the mountian to mohammad'. Why not do some > simple explainations as to why these things are good, and what > they do, and how to use them in real context? Just a matter of someone writing and submitting it ... how are your writing skills? :) > 4) As other peole have noted, there's no windows build readily > available for Postgres. There may be, but it's difficult to > find. If someone's used to running, say, Oracle, and all they > have is a windows machine to test something out on, MySQL has > compiled binaries ready to go. there is no native windows currently available, but its being worked on for 7.5 ... after which, a pre-compiled binary becomes automatic ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tue, Apr 27, 2004 at 07:55:08PM +0400, Alexey Borzov wrote: > Hi! > > Tim Conrad wrote: > >I was researching an article I wrote about a comparison between > >Postgres and MySQL recently (If you want, you can read the article > >at http://www.devx.com/dbzone/Article/20743/). I noticed some clear > >differences between the mysql.com website and the Postgres website. > > Sorry, couldn't resist: may I suggest doing the research *before* > writing an article, not *after*? > > My favourite part of it is: > -------- > MySQL uses traditional row-level locking. PostgreSQL uses something > called Multi Version Concurrency Control (MVCC) by default. MVCC is a > little different from row-level locking in that transactions on the > database are performed on a snapshot of the data and then serialized. > New versions of PostgreSQL support standard row-level locking as an > option, but MVCC is the preferred method. > -------- Nice that you point out that incorrectly stated something. Even nicer that you don't tell me what the correct answer would be. Unfortunanatly, that's the best I could come up with with doing research with the documentation I could find on the subject. MVCC does a lot more than can be easily contained in a sentance. > > >2) There doesn't seem to be a clear roadmap on Postgres features. > > When certian things are expected. There's the TODO list that > > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > > nice listing of what to expect in certian future versions. I know > > it's not a perfect list, but it'd be nice to know when full blown > > replication will be included in PostgreSQL as an example. > > MySQL's roadmap is complete bullshit. Subselects were first promised in > 4.0, which was "not that far away" [1] back in 1998! Well, they are in > 4.1, which is still alpha in 2004. I realize this. I also realize that having a nicely defined roadmap would give Postgres a hands up in this category. > > Of course, some gullible people actually believe this and compare [2] > the existing and working implementations with vaporware (MySQL 5.1, > anyone?). > > > On those same lines, there doesn't seem to be anything about the > > improvements in the minor versions. It seems that in every > > release (i.e. 7.2,7.3,7.4) there are pretty significant changes, > > but finding a place that outlines these changes is somewhat > > difficult. > > Have you tried looking in the release notes [3]? > > > [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ > [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 > [3] http://www.postgresql.org/docs/7.4/interactive/release.html I guess I'm an ignorant fool and I don't comprehend many of the items under the release note. I'm also looking for something I can hand my boss and say ' this is why we should use postgres instead of oracle'. Tim
On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote: > On Tue, 27 Apr 2004, Tim Conrad wrote: > > > 2) There doesn't seem to be a clear roadmap on Postgres features. > > When certian things are expected. There's the TODO list that > > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > > nice listing of what to expect in certian future versions. > > Not possible for us, since we have no "upper management" that dictates > what features get added, for when ... Not entirely true. I've read enough on the lists to see Bruce or others saying 'x feature isn't expected until version y.z'. Heck, to me, something that says 'we're hoping for feature x in version y.z', but it's not an exact science. See the MySQL releases as an example :) > > > I know > > it's not a perfect list, but it'd be nice to know when full blown > > replication will be included in PostgreSQL as an example. > > Never, since there is no such thing as a 'full blown replication', since > there is no *one* way to do replication ... It was puretly there for example purposes... > > > 3) There's the issues of 'advanced database features' in general. > > Many MySQL applications perform much of their logic in the > > application level, instead of the database level. They do this > > because there aren't things like triggers or stored procedures > > in MySQL. As the saying goes, 'if mohammad won't go to the > > mountain, bring the mountian to mohammad'. Why not do some > > simple explainations as to why these things are good, and what > > they do, and how to use them in real context? > > Just a matter of someone writing and submitting it ... how are your > writing skills? :) > > > 4) As other peole have noted, there's no windows build readily > > available for Postgres. There may be, but it's difficult to > > find. If someone's used to running, say, Oracle, and all they > > have is a windows machine to test something out on, MySQL has > > compiled binaries ready to go. > > there is no native windows currently available, but its being worked on > for 7.5 ... after which, a pre-compiled binary becomes automatic ... > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tim Conrad wrote: > > Of course, some gullible people actually believe this and compare [2] > > the existing and working implementations with vaporware (MySQL 5.1, > > anyone?). > > > > > On those same lines, there doesn't seem to be anything about the > > > improvements in the minor versions. It seems that in every > > > release (i.e. 7.2,7.3,7.4) there are pretty significant changes, > > > but finding a place that outlines these changes is somewhat > > > difficult. > > > > Have you tried looking in the release notes [3]? > > > > > > [1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/ > > [2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1 > > [3] http://www.postgresql.org/docs/7.4/interactive/release.html > > I guess I'm an ignorant fool and I don't comprehend many of the > items under the release note. I'm also looking for something I can > hand my boss and say ' this is why we should use postgres instead of > oracle'. I think the summary of each release at the top would be OK for that. Actually, your biggest problem is that we don't have a big motivation to _sell_ PostgreSQL to anyone. We are more driven toward solving problems and designing superior software. If it looks like we don't have a polished sales image, that's because we don't stive for that. However, we have had a large number of volunteers over the past few months focus in this area and I hope there will be visible results shortly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Tue, 27 Apr 2004, Tim Conrad wrote: > On Tue, Apr 27, 2004 at 12:58:59PM -0300, Marc G. Fournier wrote: > > On Tue, 27 Apr 2004, Tim Conrad wrote: > > > > > 2) There doesn't seem to be a clear roadmap on Postgres features. > > > When certian things are expected. There's the TODO list that > > > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > > > nice listing of what to expect in certian future versions. > > > > Not possible for us, since we have no "upper management" that dictates > > what features get added, for when ... > > Not entirely true. I've read enough on the lists to see Bruce or > others saying 'x feature isn't expected until version y.z'. Heck, to > me, something that says 'we're hoping for feature x in version y.z', > but it's not an exact science. See the MySQL releases as an example > :) Ah, then in that case, look at the TODO list, pull out all items that have a name beside them, and for those, they aren't expected until the next version .. :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > Not entirely true. I've read enough on the lists to see Bruce or > > others saying 'x feature isn't expected until version y.z'. Heck, to > > me, something that says 'we're hoping for feature x in version y.z', > > but it's not an exact science. See the MySQL releases as an example > > :) > > Ah, then in that case, look at the TODO list, pull out all items that have > a name beside them, and for those, they aren't expected until the next > version .. :) But the list is loooonng...and my brain is weeeaaaakkk. :) Seriously, though. I was looking through the list yesterday trying to figure out something, and it was kind of hard to do.But, more to my point, this stuff is in the MySQL manual, making it easy to find. (Yes. I know what MySQL includes kind of blows, but, it's better than nothing) Tim
Tim, Ok, first off, taking this thread off Hackers where it's not necessary. > Seriously, though. I was looking through the list yesterday trying > to figure out something, and it was kind of hard to do.But, more to > my point, this stuff is in the MySQL manual, making it easy to find. > (Yes. I know what MySQL includes kind of blows, but, it's better > than nothing) Well, our issue is that we have a significant phobia of announcing features that we can't deliver. A lot of us are still embarassed over the 7.4+Windows thing. And many, many other features got as far as a first-round patch and then died for a variety of reasons, or have had their development drag on for 3 years (2PC comes to mind). I guess there's a perception that we are "above" the marketeering of MySQL and Microsoft, where features are promised as much as 6 years before they appear, or are heavily publicized while still in alpha. So the most you'd be likely to get the community to commit to is maintaining a list of easy-to-read "Major Features in Development". Which wouldn't be a bad idea, at that. But not in the Docs ;-) -- Josh Berkus Aglio Database Solutions San Francisco
Tim, Folks: > I guess there's a perception that we are "above" the marketeering of MySQL > and Microsoft, where features are promised as much as 6 years before they > appear, or are heavily publicized while still in alpha. So the most you'd > be likely to get the community to commit to is maintaining a list of > easy-to-read "Major Features in Development". Actually, I really like this idea. It could go like: Feature Lead Status Improved Memory Use Jan Wieck Complete, Committed for 7.5 HA M-S Replication Jan Wieck Alpha testing PITR Simon Riggs Early Development Tablespaces Gavin Sherry Late Development Integrated pg_autovacuum Matthew O'Con. Planning Server Clustering None Developer Needed etc. As well as giving the press something to look at, this would give programmers and corporate sponsors an idea of where their time/money would be of use. And it could put to bed the myth that we're not constantly improving. -- Josh Berkus Aglio Database Solutions San Francisco
On Tue, Apr 27, 2004 at 10:39:52AM -0700, Josh Berkus wrote: > Tim, Folks: > > I guess there's a perception that we are "above" the marketeering of MySQL > > and Microsoft, where features are promised as much as 6 years before they > > appear, or are heavily publicized while still in alpha. So the most you'd > > be likely to get the community to commit to is maintaining a list of > > easy-to-read "Major Features in Development". > > Actually, I really like this idea. It could go like: > > Feature Lead Status > Improved Memory Use Jan Wieck Complete, Committed for 7.5 > HA M-S Replication Jan Wieck Alpha testing > PITR Simon Riggs Early Development > Tablespaces Gavin Sherry Late Development > Integrated pg_autovacuum Matthew O'Con. Planning > Server Clustering None Developer Needed > etc. > > As well as giving the press something to look at, this would give programmers > and corporate sponsors an idea of where their time/money would be of use. > And it could put to bed the myth that we're not constantly improving. This suggestion would be good. Something that's not super-detailed and not super-technical. Also stuff that's on the 'todo' list that is certianly long-range goals as well - just so people are aware that it's something that the 'group' is aware of as well as a need. Tim
Hi! Tim Conrad wrote: >>My favourite part of it is: >>-------- >>MySQL uses traditional row-level locking. PostgreSQL uses something >>called Multi Version Concurrency Control (MVCC) by default. MVCC is a >>little different from row-level locking in that transactions on the >>database are performed on a snapshot of the data and then serialized. >>New versions of PostgreSQL support standard row-level locking as an >>option, but MVCC is the preferred method. >>-------- > > Nice that you point out that incorrectly stated something. Even > nicer that you don't tell me what the correct answer would be. > Unfortunanatly, that's the best I could come up with with doing > research with the documentation I could find on the subject. MVCC > does a lot more than can be easily contained in a sentance. The problem is that in MySQL 1) MyISAM does table-level locking; 2) BDB does row-level locking; 3) InnoDB does MVCC (mostly) like PostgreSQL. PostgreSQL does support row-level locking (SELECT ... FOR UPDATE), table-level locking (LOCK TABLE ...), though this does not *replace* MVCC, as one may understand from the quotation. >>MySQL's roadmap is complete bullshit. Subselects were first promised in >>4.0, which was "not that far away" [1] back in 1998! Well, they are in >>4.1, which is still alpha in 2004. > > I realize this. I also realize that having a nicely defined roadmap would > give Postgres a hands up in this category. A hands up in *what* category? In bragging? Should PostgreSQL developers write something along the lines of "PostgreSQL 9i (available Really Soon Now) will also be able to make coffee"? Well, as you know about coffee now, why don't you add "make coffee" to your comparison table, with empty space in MySQL's and commercial DBMSs' columns and "in 9i" in PostgreSQL's one?
On Tue, Apr 27, 2004 at 12:57:46PM -0400, Tim Conrad wrote: > Seriously, though. I was looking through the list yesterday trying > to figure out something, and it was kind of hard to do.But, more to > my point, this stuff is in the MySQL manual, making it easy to find. > (Yes. I know what MySQL includes kind of blows, but, it's better > than nothing) You know, that's kind of the point of all things related to MySQL. "It's better than nothing." PostgreSQL doesn't do things because "it's better than nothing." My first patch here was rejected, not because it didn't do anything useful (it did), but because "it didn't solve the complete problem." I had to do a lot more work to get it accepted. Similarly, people here don't want to showcase a list of things that will be on the next release, because we _don't know_ what will be on the next release. There are guesses, but guesses are not good enough. (Same as how MySQL guesses the result of a modulo operation, and gets it wrong. They don't care and you can read that on the manual. In Postgres, this is a bug.) In PostgreSQL there are no guesses. There are certainties. And I think this it how it should be for a database server ;-) -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "No hay cielo posible sin hundir nuestras raíces en la profundidad de la tierra" (Malucha Pinto)
Alexey Borzov wrote: > Hi! > > Tim Conrad wrote: > >>> My favourite part of it is: >>> -------- >>> MySQL uses traditional row-level locking. PostgreSQL uses something >>> called Multi Version Concurrency Control (MVCC) by default. MVCC is >>> a little different from row-level locking in that transactions on >>> the database are performed on a snapshot of the data and then >>> serialized. New versions of PostgreSQL support standard row-level >>> locking as an option, but MVCC is the preferred method. >>> -------- >> >> >> Nice that you point out that incorrectly stated something. Even >> nicer that you don't tell me what the correct answer would be. >> Unfortunanatly, that's the best I could come up with with doing >> research with the documentation I could find on the subject. MVCC >> does a lot more than can be easily contained in a sentance. > > > The problem is that in MySQL > 1) MyISAM does table-level locking; > 2) BDB does row-level locking; > 3) InnoDB does MVCC (mostly) like PostgreSQL. > > PostgreSQL does support row-level locking (SELECT ... FOR UPDATE), > table-level locking (LOCK TABLE ...), though this does not *replace* > MVCC, as one may understand from the quotation. > >>> MySQL's roadmap is complete bullshit. Subselects were first promised >>> in 4.0, which was "not that far away" [1] back in 1998! Well, they >>> are in 4.1, which is still alpha in 2004. >> >> >> I realize this. I also realize that having a nicely defined roadmap >> would >> give Postgres a hands up in this category. > > > A hands up in *what* category? In bragging? > > Should PostgreSQL developers write something along the lines of > "PostgreSQL 9i (available Really Soon Now) will also be able to make > coffee"? > > Well, as you know about coffee now, why don't you add "make coffee" to > your comparison table, with empty space in MySQL's and commercial > DBMSs' columns and "in 9i" in PostgreSQL's one? > Maybe. Just for jest-- If you read the Linux Coffee how-to, write a C module, get the right hardware, etc. Yes, PostgreSQL can make coffee! Of course, this would occur outside any sort of transactional control... Seriously, though... I think that it would be helpful to have a list of features which are under active development (not just the ToDo list which are features which we want to develop). We could also have contact info for leads (or maybe a contact via a web form, etc.) as well as status for that feature. As the lead in a project whose roadmap has changed many times due to paid contracts, I don't really see the value of published roadmaps in general. Best Wishes, Chris Travers
Alexey Borzov wrote: >> I realize this. I also realize that having a nicely defined roadmap >> would >> give Postgres a hands up in this category. > > > A hands up in *what* category? In bragging? In telling your boss, "I think we should use Postgresql." It's likely he's not stupid, and it's reasonable for him to say "since I'm tying my own success to this software, I want to have some indication as to where this software is going to go." Something like Josh Berkus' table of features would be very nice. (I've worked with sales teams at my various former employers, and the best things you can provide them are documents (feature descriptions, competitive analyses, white papers, etc) that your customer contact can use as the basis for his own justification to buy your product. All of this can be summarized as "make it easy for people to help you.") Cheers, Mark -- Mark Harrison Pixar Animation Studios
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 <zakkr@zf.jcu.cz> http://home.zf.jcu.cz/~zakkr/
Dear Tim, These are execellent proposals. My only remark would be to build a step-by-step approach. In a first stage, we could set-up a minimal web page for the Win32 port: - PostgreSQL Win32 installer (possibly translated), - translation of the web page in 40 languages, - step-by-step installation under Win32 (screenshots), - links (NLS project, documentation), ... advertise (example: http://www.pgadmin.org/pgadmin3/advocacy.php) and start monitoring downloads. With PostgreSQL Win32 version and looking at pgAdmin III statistics, reaching one million downloads every month seems a reasonable target. PostgreSQL is such a wonderful community project that there is no need to build complex marketing strategies to reach impressive goals. In a second stage, we can start building a rich web site (as you proposed) and make it live on the long run. Best regards, Jean-Michel > I've been sort-of reading this thread off and on, so this may > contain duplicate suggestions. > > I was researching an article I wrote about a comparison between > Postgres and MySQL recently (If you want, you can read the article > at http://www.devx.com/dbzone/Article/20743/). I noticed some clear > differences between the mysql.com website and the Postgres website. > > 1) Since MySQL AB supports and trains for MySQL, there's loads of > training information available on their website. On the other > hand, I had a hard time finding training information for Postgres > in general. Same goes for support. It's easier to find, but it's > still somewhat convoluted, IMO. > > 2) There doesn't seem to be a clear roadmap on Postgres features. > When certian things are expected. There's the TODO list that > Bruce maintains, but it only outlines 'near' fixes. MySQL has a > nice listing of what to expect in certian future versions. I know > it's not a perfect list, but it'd be nice to know when full blown > replication will be included in PostgreSQL as an example. > On those same lines, there doesn't seem to be anything about the > improvements in the minor versions. It seems that in every > release (i.e. 7.2,7.3,7.4) there are pretty significant changes, > but finding a place that outlines these changes is somewhat > difficult. > While being somewhat nit-picky on this, it'd also be helpful if > someone wasn't completely database literate could understand some > of the changes. Who needs transactions, anyways? :) > > 3) There's the issues of 'advanced database features' in general. > Many MySQL applications perform much of their logic in the > application level, instead of the database level. They do this > because there aren't things like triggers or stored procedures > in MySQL. As the saying goes, 'if mohammad won't go to the > mountain, bring the mountian to mohammad'. Why not do some > simple explainations as to why these things are good, and what > they do, and how to use them in real context? > > 4) As other peole have noted, there's no windows build readily > available for Postgres. There may be, but it's difficult to > find. If someone's used to running, say, Oracle, and all they > have is a windows machine to test something out on, MySQL has > compiled binaries ready to go. > > 5) I believe that this was noted as well somewhere along the line - > the other tools, like pgadmin III aren't readily available > either. They're excellent tools, and they should be quick to > find on the postgres website. > > 6) Bug tracking. I haven't really looked into how MySQL handles > this, but when learning about Postgres, I discovered that the > whole development model seemed kind of 'closed', and people on > the mailing lists would find bugs repeatedly. Something like > Bugzilla would be very helpful in this respect. I've been kind > of out of the loop for the past 6 months in this area, so it may > have changed since then. > > 7) The two Postgres books are available online for anyone to read > and download. They're there, but, to me, you have to notice them > on the sidebar to go to them. They're extremely helpful, and > they should be pointed out more. > > > Most of these suggestions aren't really anything to do with the > database itself. It's simply a re-organization of some of the > information that's already available. As others have mentioned, > 'it's about the PR'. > > Just my $.02 worth. > > Tim > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
Tim Conrad wrote: >On Tue, Apr 27, 2004 at 10:39:52AM -0700, Josh Berkus wrote: > > >>Tim, Folks: >> >> >>>I guess there's a perception that we are "above" the marketeering of MySQL >>>and Microsoft, where features are promised as much as 6 years before they >>>appear, or are heavily publicized while still in alpha. So the most you'd >>>be likely to get the community to commit to is maintaining a list of >>>easy-to-read "Major Features in Development". >>> >>> >>Actually, I really like this idea. It could go like: >> >>Feature Lead Status >>Improved Memory Use Jan Wieck Complete, Committed for 7.5 >>HA M-S Replication Jan Wieck Alpha testing >>PITR Simon Riggs Early Development >>Tablespaces Gavin Sherry Late Development >>Integrated pg_autovacuum Matthew O'Con. Planning >>Server Clustering None Developer Needed >>etc. >> >>As well as giving the press something to look at, this would give programmers >>and corporate sponsors an idea of where their time/money would be of use. >>And it could put to bed the myth that we're not constantly improving. >> >> > >This suggestion would be good. Something that's not super-detailed >and not super-technical. Also stuff that's on the 'todo' list that >is certianly long-range goals as well - just so people are aware >that it's something that the 'group' is aware of as well as a need. > > > The big issue I see with this is maintenance. Ideally, it would be handled in a DB-driven web app and maybe even tied to the TODO (when an item is listed as committed, the item gets the leading - in the TODO?). I would be happy to contribute programming time, but I would need to leave the maintenance to others. Best Wishes, Chris Travers
Attachment
Le mardi 27 Avril 2004 09:59, Karel Zak a écrit : > Agree. The page should be describe basic PostgreSQL features and > step-by-step introduction from download to a first user's "SELECT ... > FROM". Dear Karel and Bruce, A step-by-step introduction is interesting, to the extent that the http://win32.postgresql.org home page remains minimal, so that translators do not need to upgrade their translation from time to time. At first, five paragraphs are enough: - Presentation of PostgreSQL: "PostgreSQL is the most advanced database in the world, offering a complete solution suited for every need, etc...". - Step by step installation procedure (with screenshots). The screenshots may remain in English. - Links to the documentation and the mailing lists. - Links to the PostgreSQL NLS project (Peter). - Legal disclaimer. Having a translation is important because people running Windows mostly seek information in their language on seach engines. Then, like in the pgAdmin III project, you can sit on a chair and monitor downloads. IMHO, the number of downloads can quickly rise to one million a month. > Do you expect translate PostgreSQL-win installer to foreign languages? Probably not, this is too much work. But this can come in a second stage. Because PostgreSQL is such a wonderfull project, there is no need to build complex marketing strategies. A single web page and a complete installer is enough to reach impressive numbers. Of course, the most difficult part is the Win32 installer. Cheers, Jean-Michel Pouré
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: > You know, that's kind of the point of all things related to MySQL. > "It's better than nothing." PostgreSQL doesn't do things because "it's > better than nothing." <snip> > (Same as how MySQL guesses the result of a modulo operation, and gets it > wrong. They don't care and you can read that on the manual. In > Postgres, this is a bug.) > Hey Alvaro, are you familiar with "worse is better" philosphy in software development and how that leads to adoption rates? It basically states that simplicity is the ultimate design goal over correctness, consitency, and completness. Because of this more people are able to quickly adopt a technology, which allows the incorrectness/inconsistency/incompletness to be address by new comers and gradually bring the software up to higher standards. I was reading some blogs the other day that applied this to PHP's adoption rate over Java and .net, but your comment made me think this really applies to my$ql and postgresql as well. check out http://www.sitepoint.com/forums/showpost.php?p=1121502&postcount=2 for a bit more. Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: > > You know, that's kind of the point of all things related to MySQL. > > "It's better than nothing." PostgreSQL doesn't do things because "it's > > better than nothing." <snip> > > (Same as how MySQL guesses the result of a modulo operation, and gets it > > wrong. They don't care and you can read that on the manual. In > > Postgres, this is a bug.) > > > > Hey Alvaro, > are you familiar with "worse is better" philosphy in software development and > how that leads to adoption rates? It basically states that simplicity is the > ultimate design goal over correctness, consitency, and completness. Because > of this more people are able to quickly adopt a technology, which allows the > incorrectness/inconsistency/incompletness to be address by new comers and > gradually bring the software up to higher standards. I was reading some > blogs the other day that applied this to PHP's adoption rate over Java and > .net, but your comment made me think this really applies to my$ql and > postgresql as well. check out > http://www.sitepoint.com/forums/showpost.php?p=1121502&postcount=2 for a bit > more. Interesting analysis. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Tue, May 04, 2004 at 03:06:53PM -0400, Robert Treat wrote: > On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: > > You know, that's kind of the point of all things related to MySQL. > > "It's better than nothing." PostgreSQL doesn't do things because "it's > > better than nothing." <snip> > > (Same as how MySQL guesses the result of a modulo operation, and gets it > > wrong. They don't care and you can read that on the manual. In > > Postgres, this is a bug.) > > Hey Alvaro, > are you familiar with "worse is better" philosphy in software development and > how that leads to adoption rates? Yeah, I've read about it. I'm not sure which side of the do I sit on, though. The wikipedia entry may be a good read: http://en.wikipedia.org/wiki/Worse_is_better Note that it puts correctness and consistency after simplicity, but this not means that they are completely put away. I think SQL (as in "SQL standard") is not modelled after this idea: SQL tries to be complete rather than simple. I may be wrong though. Certainly MySQL does away with completeness and tries to achieve simplicity, while the opposite could be said of Postgres. Fortunately, Postgres has apparently caught up with developer mass, so it may yet be able to win against MySQL ... -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo" (Jaime Salinas)
Robert Treat <xzilla@users.sourceforge.net> writes: > On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote: >> You know, that's kind of the point of all things related to MySQL. >> "It's better than nothing." PostgreSQL doesn't do things because >> "it's better than nothing." <snip> (Same as how MySQL guesses the >> result of a modulo operation, and gets it wrong. They don't care >> and you can read that on the manual. In Postgres, this is a bug.) >> > > Hey Alvaro, are you familiar with "worse is better" philosphy in > software development and how that leads to adoption rates? It > basically states that simplicity is the ultimate design goal over > correctness, consitency, and completness. Because of this more > people are able to quickly adopt a technology, which allows the > incorrectness/inconsistency/incompletness to be address by new > comers and gradually bring the software up to higher standards. I > was reading some blogs the other day that applied this to PHP's > adoption rate over Java and .net, but your comment made me think > this really applies to my$ql and postgresql as well. check out > http://www.sitepoint.com/forums/showpost.php?p=1121502&postcount=2 > for a bit more. The problem with the "Worse is Better" philosophy is that it almost totally overlooks price, which is arguably the most important factor in deciding which technologies get adopted. The real trick is being "good enough" at the lowest price. When MySQL became the de-facto web database (back in the Postgres95 and Postgres 6.X days) PostgreSQL simply wasn't "good enough" for most sites. PostgreSQL, in those days, was slow, buggy, and decidedly non-standard (anyone else remember PostQUEL). On the plus side I personally don't think that Free Software databases have really hit their stride yet, and I believe that when they do PostgreSQL is going to be front and center. MySQL is a pretty handy datastore, but PostgreSQL is a far more useful tool for creating complex applications. Jason