Thread

What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T04:09:45Z

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/2229212&mode=nested&tid=137&tid=185&tid=187&tid=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?
	
-- 
  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

Re: [HACKERS] What can we learn from MySQL?

David Garamond <lists@zara.6.isreserved.com> — 2004-04-23T06:05:21Z

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

Re: What can we learn from MySQL?

Christopher Kings-Lynne <chriskl@familyhealth.com.au> — 2004-04-23T06:35:48Z

> 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:

I have already told Bruce at length about the single most common 
complaint in the phpPgAdmin lists and in the IRC channel: the inability 
to change column types.  I think we should listen to the punters on that 
one.

Also, how about a new section in the manual: PostgreSQL for MySQL users 
and PostgreSQL for Oracle users?

Chris

Re: [HACKERS] What can we learn from MySQL?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-23T07:11:11Z

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/2229212&mode=nested&tid=137&tid=185&tid=187&tid=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/

Re: What can we learn from MySQL?

Jeff Davis <jdavis-pgsql@empires.org> — 2004-04-23T08:08:30Z

On Thu, 2004-04-22 at 21:09, 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.
> 

One common thing people talk about is ease of use. However that puzzles
me, since it takes all of (about) three commands to install postgresql
and log into the database for the first time. I use debian, so it
amounts to "apt-get install", su to "postgres" and "psql template1".

I suspect some of the difficulties lie in how distributions of linux (a
large part of the pg user base) present postgres.

Postgres is a server system, and the only real interface it provides is
SQL, and "CREATE TABLE" and other simple commands are the same as in
MySQL. How can it be easier to use?

I think debian does a great job, do other distros make it so easy?

Here are some ideas at the distribution level:

	o  Ask a question during install to create a database other than
	   template0 and template1.
	o  If it's a GUI-based distro, install and lauch pgadmin3 and
	   provide some icons.
	o  If it's a GUI distro, lauch a browser to a special tutorial
	   at the distributors website so that users can see instantly
	   how to start doing things without going through the install
	   instructions or instructions about how to create a new
	   database. It should show pgadmin3 and show how to execute
	   queries (and provide the same simple examples you see in any
	   SQL tutorial), and then later show how to use psql from the
	   command line.
	o  If it's being installed from the command line, maybe have a
	   final question "Launch PgSQL quickstart?" that would run a
	   script to provide instructions interactively, like saying
	   "Now type createdb ... this will make a starting database",
	   "now type psql ...", "now type CREATE TABLE ...".
	o  If you look at windows packages, even servers, there's always
	   an interface to click on and then "browse around". This
	   interface detects the fact that something is installed and
	   allows you to administer it somehow.

Those are just ideas. MySQL doesn't do any of that, so I can't really
see how people say it's easier.

One very legitimate concern is the PostgreSQL site's search
functionality. I really like php.net, and I think MySQL tries to make
their website like PHP's. That requires manpower, and we've already
discussed that on this list.

Overall, I think that the PostgreSQL project has done everything very
well. It compiles very nicely and provides a lot of tools. Beyond that,
we just need adoption from application developers, distributions who
spend more time making PostgreSQL easy to use, and ISPs.

I don't know what you mean by "too technically driven". I guess the
release process of postgresql isn't very marketing friendly. Often what
happens with development being as open as it is here, is that people get
excited about a set of new features, and not all of them make it in to
the next release. From the outside it looks like postgres is slow and
not providing many new features. Maybe we should throw old features into
the press release just to remind people that postgres has had the
features for years :)  (i.e. "7.5 has native win32 support, and yes, it
still has foreign keys and stored procedures, and yes, they even work in
win32!" might work, assuming of course that win32 is ready for release
at that time).

Regards,
	Jeff Davis

Re: [HACKERS] What can we learn from MySQL?

Jeff Davis <jdavis-pgsql@empires.org> — 2004-04-23T08:16:38Z

> I have already told Bruce at length about the single most common 
> complaint in the phpPgAdmin lists and in the IRC channel: the inability 
> to change column types.  I think we should listen to the punters on that 
> one.
> 

Maybe a simple and less dangerous option would be to add a column of the
new type, rename the old column and hide it, and select from the old
column and cast it to the new column? Is that a feasible implementation?
If I really need to change a column, that's what I'd do.

It's certainly less dangerous than MySQL. I remember a horror story
watching my column silently cast itself to a bunch of blank values in
MySQL. In postgres you'd just be able to undo it or fix the problem
since the data is still there. I also understand that MySQL has to copy
the entire table or something insane like that, so we could use the
opportunity to brag about how much more efficient we are for large
tables.

	Regards,
		Jeff Davis

Re: [HACKERS] What can we learn from MySQL?

Fabien COELHO <coelho@cri.ensmp.fr> — 2004-04-23T08:25:58Z

> 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 - coelho@cri.ensmp.fr

Re: What can we learn from MySQL?

Francois Suter <dba@paragraf.ch> — 2004-04-23T08:27:53Z

> I think debian does a great job, do other distros make it so easy?

On Mac OS X, there's Marc Liyanage's binary package, which is about as 
simple as it gets to install. But PostgreSQL also compiles pretty 
nicely out of the box.

So I think it is really more a question of being known and known in a 
good light.

Also on Mac OS X Server, MySQL is included by default. Has anyone tried 
to lobby Apple about including PostgreSQL too?

Cheers.

---------------
Francois

Home page: http://www.monpetitcoin.com/

"If liberty means anything at all, it means the right to tell people 
what they do not want to hear." - George Orwell

Re: [HACKERS] What can we learn from MySQL?

Karel Zak <zakkr@zf.jcu.cz> — 2004-04-23T08:52:32Z

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  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

Re: [HACKERS] What can we learn from MySQL?

Dennis Björklund <db@zigo.dhs.org> — 2004-04-23T09:22:33Z

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

Re: [HACKERS] What can we learn from MySQL?

Hans-Jürgen Schönig <postgres@cybertec.at> — 2004-04-23T09:47:31Z

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

Re: What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-23T10:47:59Z

Hi!

Jeff Davis 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.
> 
> One common thing people talk about is ease of use. However that puzzles
> me, since it takes all of (about) three commands to install postgresql
> and log into the database for the first time. I use debian, so it
> amounts to "apt-get install", su to "postgres" and "psql template1".

"Ease of use" == "I would like to install it on my precious-s-s win* 
without this horrible Cygwin"

No more, no less.

> One very legitimate concern is the PostgreSQL site's search
> functionality. I really like php.net, and I think MySQL tries to make
> their website like PHP's. That requires manpower, and we've already
> discussed that on this list.

"discussed" is good, but where's that "manpower"?

Re: What can we learn from MySQL?

Robert Bernier <robert.bernier5@sympatico.ca> — 2004-04-23T11:07:41Z

Rather than contining with the answers that you and the others have 
contributed to the thread I'm going to respond to this first posting.

The first link that you've quoted is a mixture of fact that I can agree 
with and an excuse to express an ego.

I was first introduced to pc based databases back around when DBase came 
out. DBase II was not that good but DBase-III+ was what set the measure 
for everything else that came onto the PC, including oracle. Ironically 
the blog that you've listed is a demonstration of the success of the 
human desire to justify ones value system by converting others. What 
drove the development of sql related technology has less to do with 
technology and more to do with psychology and human nature.

In my opinion MySQL became popular because of the internet (no news 
there). I still remember the days when a person could get paid $300 for 
composing one html page. People get spoilt making this kind of money so 
when companies like microsoft started putting out products that 
simplified html composing, like frontpage, thus allowing less skilled 
children onto the market, the html page composers saw the writing on the 
wall and started hunting for the next 'evolution'  which was of course 
dynamic pages.

Netscape was king in those days and javascript made a great impression 
on the community. What a concept to be able to change the way a page 
looked and acted. So now the emphasis was instead of making money on a 
static page it would be a dynamic one.

The more popular a technology is the higher the elite must raise the bar 
to continue making gobs of money. So as more people jumped on the 
bandwagon we had to look at other ways of expanding the word 'dynamic'. 
Enter databased information.

Meanwhile, as html was getting more complicated we had taken our 
classically trained views of programming languages and applied it to 
server side includes and to javascript. But javascript is such a bitch 
so cgi remained important until larry showed up and changed the paradign 
by looking at the person rather than the language (remember larry's a 
linguist) and we stared using perl.

So now people started using databased technology on the internet. 
Remember, I speak of the grass roots and not that very small minority of 
DBA's that had a real understanding of databases. MySQL became popular, 
it "bragged" (this is the point folks) that you could attach your 
programming language to it and get good results. And for what it's is 
worth, this was true. People hate to change and need to justify their 
decisions in life with the money they make so programming stayed outside 
of the database for a long time giving MySQL time to evolve.

The reason why MySQL remains relevant because it grew up at rate that 
the grass roots expectations grew.

PostgreSQL is different, it was never part of this movement because of 
its roots. Using this view of history I would argue that Pg is the 
newcomer and MySQL is the veteran.

If we want to reach the 'popular' masses then we need to consider the 
psychology of the internet ... go after the grass roots by convincing 
them that their jobs are on the line if they don't learn proper 
relational theory. Show them! Give them examples!

There's three phases to software development:
- programming
- debugging
- documentation

You old timers have done the first two. Now it's time to address the 
last one. And if you don't agree with what I say it may not perhaps be 
so much because I'm wrong but because you have not invested your 
self-image into that activity. Success is about figuring out what 
everybody wants before they do. And the measure of success is not 
technology its money.

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/2229212&mode=nested&tid=137&tid=185&tid=187&tid=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?
>	
>  
>

Re: [HACKERS] What can we learn from MySQL?

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-23T11:45:54Z

Dennis Bjorklund <db@zigo.dhs.org> 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

Re: What can we learn from MySQL?

David Costa <geeks@dotgeek.org> — 2004-04-23T12:32:50Z

On Apr 23, 2004, at 8:35 AM, Christopher Kings-Lynne 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.
>> Questions I have are:
>
> I have already told Bruce at length about the single most common 
> complaint in the phpPgAdmin lists and in the IRC channel: the 
> inability to change column types.  I think we should listen to the 
> punters on that one.
>
> Also, how about a new section in the manual: PostgreSQL for MySQL 
> users and PostgreSQL for Oracle users?

Hello Bruce, Chris and everyone,
So far I have offered free PHP5/ PostgreSQL hosting to around 800 
developers that signed up on dotgeek.org
I gathered a number of feedback.

Overall many PHP developers are extremely impressed by PostgreSQL but 
they never had the chance/found a reason to try it.

The issues are related mainly to the syntax. Here MySQL, by using non 
standards systems, is making the move not that easy to many developers.

Marketing is an important point, so is being able to let the highest 
number of people to try PostgreSQL and see the difference.
Another problem is, as far as I can say, their easier to search and 
more user friendly manual. I know that Alexey is working on that so I 
will think about a way
to contribute directly. Users  (and monitored) comments are a must IMHO.

Cheers
David Costa

>
> Chris
>
>
> ---------------------------(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 <matthew@zeut.net> — 2004-04-23T12:58:41Z

> 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

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T13:03:13Z

Christopher Kings-Lynne 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.
> > 
> > Questions I have are:
> 
> I have already told Bruce at length about the single most common 
> complaint in the phpPgAdmin lists and in the IRC channel: the inability 
> to change column types.  I think we should listen to the punters on that 
> one.

Yea, I will push that for 7.5.

-- 
  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

Re: [HACKERS] What can we learn from MySQL?

Matthew T. O'Connor <matthew@zeut.net> — 2004-04-23T13:37:32Z

>> 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.

Re: What can we learn from MySQL?

Peter Eisentraut <peter_e@gmx.net> — 2004-04-23T13:45:49Z

Am Freitag, 23. April 2004 06:09 schrieb Bruce Momjian:
> 	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?

Success is not measured by absolute number of installations.  You can measure 
success by having enough users so that the project can continue, enough users 
so you can make a living, more satisfied users than unsatisfied ones, more 
heavy-duty installations than personal database-driven websites, and by 
having a product that you feel good about.  The only way to position 
ourselves is as the relational database with the best price/performance 
ration (price = TOC, performance = features + speed).  And the only way to 
achieve any of these goals is by focussing on technology and ease of use.  
For the crowd out there, PostgreSQL is an exciting and growing topic.  That's 
more important than the installation count.

Re: [HACKERS] What can we learn from MySQL?

Fabien COELHO <coelho@cri.ensmp.fr> — 2004-04-23T14:13:52Z

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 - coelho@cri.ensmp.fr

Re: What can we learn from MySQL?

Rod Taylor <pg@rbt.ca> — 2004-04-23T14:26:58Z

> One common thing people talk about is ease of use. However that puzzles
> me, since it takes all of (about) three commands to install postgresql
> and log into the database for the first time. I use debian, so it
> amounts to "apt-get install", su to "postgres" and "psql template1".

My present theory is that most users make the decision regarding ease of
use before even installing the software.

If you look at the MySQL website within 1 or 2 clicks, you know that
there is a gui for queries, a gui for administration, drivers or
interfaces for many programming langauges. They have GIS, Unicode, full
text searching, multi-master replication, ANSI compliance, etc.

Not that all of those items are necessarily true, but that is what the
user believes.


In contrast, from the PostgresSQL website I know PostgreSQL can deal
with a large dataset, has lots of backend features, supports many
languages. Looking hard enough you might find a link to the
pgreplication which currently has the goal of integrating with
PostgreSQL 7.2 ;)

You don't learn anything about the GUIs (any of them) within the first
couple of clicks. Since many users (even linux users) associate command
lines with difficulty of use, the first impression is that PostgreSQL is
difficult to use.

Re: What can we learn from MySQL?

Rod Taylor <pg@rbt.ca> — 2004-04-23T14:28:59Z

> > One very legitimate concern is the PostgreSQL site's search
> > functionality. I really like php.net, and I think MySQL tries to make
> > their website like PHP's. That requires manpower, and we've already
> > discussed that on this list.
> 
> "discussed" is good, but where's that "manpower"?

If we have a good idea of what it is we want, I'll volunteer to write
it.

Re: [HACKERS] What can we learn from MySQL?

Thomas Swan <tswan@idigx.com> — 2004-04-23T15:00:06Z

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!

Re: [HACKERS] What can we learn from MySQL?

Dave Cramer <pg@fastcrypt.com> — 2004-04-23T15:07:20Z

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

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T15:42:07Z

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
  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

Re: [HACKERS] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T15:45:28Z

On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
> 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.
> 

I know this to be true, but don't fully understand it... if our default
behavior is to fold lower, and we change it to just fold upper... then
in theory this shouldn't break anything since what used to be folder
lower will now simply be folder upper. the only people who will have a
problem are those who quote on one end but not the other, which is bad
practice anyways...  so i would say if your serious about it, make the
patch as GUC "case_folding" for upper or lower and get a taste for what
breaks inside the db. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [HACKERS] What can we learn from MySQL?

Matthew T. O'Connor <matthew@zeut.net> — 2004-04-23T15:52:14Z

> 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

Re: [HACKERS] What can we learn from MySQL?

Matthew T. O'Connor <matthew@zeut.net> — 2004-04-23T15:55:53Z

> On Fri, 23 Apr 2004 11:07:20 -0400
> Dave Cramer <pg@fastcrypt.com> 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.

Re: What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-23T16:07:54Z

Hi!

Rod Taylor wrote:
> My present theory is that most users make the decision regarding ease of
> use before even installing the software.
> 
> If you look at the MySQL website within 1 or 2 clicks, you know that
> there is a gui for queries, a gui for administration, drivers or
> interfaces for many programming langauges. They have GIS, Unicode, full
> text searching, multi-master replication, ANSI compliance, etc.
> 
> ...
> 
> You don't learn anything about the GUIs (any of them) within the first
> couple of clicks. Since many users (even linux users) associate command
> lines with difficulty of use, the first impression is that PostgreSQL is
> difficult to use.

I think that PostgreSQL's "download" page should point to at least
* Recommended replication solution (erserver?)
* Recommended full-text search solution (tsearch?)
* Recommended GUI / web frontend (PGAdmin / phpPgAdmin)
* Drivers: ODBC, JDBC, whatever
* PostGIS
* Banners to put on the website
* A description of what to find in the contrib dir

If someone makes such a page, I'll promptly add it to the 
"next-generation" site.

Re: What can we learn from MySQL?

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-23T16:39:41Z

On Fri, 23 Apr 2004, 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/2229212&mode=nested&tid=137&tid=185&tid=187&tid=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.

My immediate rhetorical response is "What could the Tortoise learn from 
the Hare?"

I think we all know which is which in my question.

> Questions I have are:
> 
> 	o  Are we marketing ourselves properly?

I'm never sure about this.  I think the best marketing is experienced 
users selling pg to their bosses one at a time.  While our MSSQL servers 
at work have died under load innumerable times, our small collection of 
postgresql servers (one's so old and embedded it's running 6.4) have been 
very reliable.  So, slowly but surely, PostgreSQL is proving itself here.

> 	o  Are we focused enough on ease-of-use issues?

Enough for me, but I don't think databases should necessarily be all that 
easy to use by people who don't understand basic relational theory.  So 
for me, ease of use means things like transactable DDL and well indexed, 
well written documentation.  I suspect ease of use for my boss is 
something entirely differnt, and may have to do with why he bought the EMS 
postgresql manager packages he did.

> 	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)

Hey, we're like the porridge in goldilock's, just right... :-)

dba folks don't pick MySQL, because it's so limited and basically has 
so many bugs (it's a feature that we don't bounds check data!)  And it's 
pretty easy to get an Oracle guy to play with postgresql when you show him 
things like transactionable DDL.

> 	o  Are our priorities too technically driven?

I don't think so.  But I'm a database / coder geek.  :-)

Re: [HACKERS] What can we learn from MySQL?

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-23T16:46:18Z

On Fri, 23 Apr 2004, Robert Treat wrote:

> On Fri, 2004-04-23 at 05:22, Dennis Bjorklund wrote:
> > 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.
> >
>
> I know this to be true, but don't fully understand it... if our default
> behavior is to fold lower, and we change it to just fold upper... then
> in theory this shouldn't break anything since what used to be folder
> lower will now simply be folder upper. the only people who will have a
> problem are those who quote on one end but not the other, which is bad
> practice anyways...  so i would say if your serious about it, make the
> patch as GUC "case_folding" for upper or lower and get a taste for what
> breaks inside the db.

I've tried just changing the parser to unconditionally casefold to upper.
First thing that happens is that initdb breaks. In addition, you have
potential issues with comparisons against the catalog's versions of
standard functions as such if you allow the case folding to be changed
after the catalogs are setup.

Re: [HACKERS] What can we learn from MySQL?

D'Arcy Cain <darcy@druid.net> — 2004-04-23T16:47:16Z

On Fri, 23 Apr 2004 11:07:20 -0400
Dave Cramer <pg@fastcrypt.com> 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 <darcy@{druid|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.

Re: What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-23T17:03:17Z

Bruce,

Hmmm ... lessons of MySQL:

-- Marketing matters more than technical quality
   (not news, Microsoft taught us that)
-- You can often get away with pretending to have features
   you don't actually have with enough spin
   (Microsoft also outshines MySQL in this area)
-- Educated Database Administrators are in short supply,
   and as a result nobody cares about the SQL standard or
   relational theory anymore
   (Fabian Pascal could have told you that; according to him, 
    the whole DB industry has been in steady decline since 1994)
-- Commerical companies are uncomfortable with Real Open Source,
   and prefer the pseudo-open-source offered by dual-licensing
   companies
   
This last lesson was really driven home to me at the Open Source Business 
Convention; managers were slavering all over "dual licensing" as the "new 
model of open source."   When I pointed out that there's another name for 
dual licensing -- "shareware" -- I got some real uncomfortable silences.   
Seems that a lot of companies want the fruits of Open Source without changing 
the way they do business at all.  Big surprise, eh?


-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T17:08:30Z

D'Arcy J.M. Cain wrote:
> On Fri, 23 Apr 2004 11:07:20 -0400
> Dave Cramer <pg@fastcrypt.com> 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
  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

Re: [HACKERS] What can we learn from MySQL?

Andrew Dunstan <andrew@dunslane.net> — 2004-04-23T17:11:54Z

Stephan Szabo wrote:

>>I know this to be true, but don't fully understand it... if our default
>>behavior is to fold lower, and we change it to just fold upper... then
>>in theory this shouldn't break anything since what used to be folder
>>lower will now simply be folder upper. the only people who will have a
>>problem are those who quote on one end but not the other, which is bad
>>practice anyways...  so i would say if your serious about it, make the
>>patch as GUC "case_folding" for upper or lower and get a taste for what
>>breaks inside the db.
>>    
>>
>
>I've tried just changing the parser to unconditionally casefold to upper.
>First thing that happens is that initdb breaks. In addition, you have
>potential issues with comparisons against the catalog's versions of
>standard functions as such if you allow the case folding to be changed
>after the catalogs are setup.
>
>  
>

ISTM that rather than a having a GUC setting, initdb would be the right 
time to make this choice. I'm not saying it would be easy, but it seems 
(without looking into it deeply) at least possible.

cheers

andrew

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T17:13:19Z

Josh Berkus wrote:
> This last lesson was really driven home to me at the Open Source Business 
> Convention; managers were slavering all over "dual licensing" as the "new 
> model of open source."   When I pointed out that there's another name for 
> dual licensing -- "shareware" -- I got some real uncomfortable silences.   
> Seems that a lot of companies want the fruits of Open Source without changing 
> the way they do business at all.  Big surprise, eh?

Agreed.  I see dual-license as an interim step for companies moving from
close to true open source.

-- 
  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

Re: [HACKERS] What can we learn from MySQL?

D'Arcy Cain <darcy@druid.net> — 2004-04-23T17:13:54Z

On Fri, 23 Apr 2004 13:08:30 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us> 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 <darcy@{druid|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.

Re: What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-23T17:26:04Z

Bruce,

> Agreed.  I see dual-license as an interim step for companies moving from
> close to true open source.

Actually, I don't.    

As I said, dual-license companies aren't really OSS companies.  They are 
shareware companies, and as such closer to proprietary software than OSS. 
Futher, these shareware companies *never* move in the direction of being more 
open as they grow -- they always become more proprietary.   See MySQL, VA 
Systems, Sendmail for examples.   Only BerkelyDB seems to have been able to 
avoid getting more proprietary with time.

In fact, I'd say that it's more likely for a 100% proprietary company to 
open-source a product than for a shareware company to go fully OSS.   See, 
for the shareware companies, OSS is a marketing and distribution model to 
help them with growing their market share -- and not how their development or 
organization works.  Once they are established in the market, they will toss 
their OSS facade like a successful junior manager dumps his old hand-me-down 
suit he wore to the interview when he gets if first paycheck.

For the customers of such shareware, it's really just a cheaper alternative to 
existing offerings -- they don't care about or understand OSS, they just want 
to be able to license database servers at MySQL's $500 each instead of 
Microsoft's $5000 each.  The only real benefit is that because shareware 
software wraps itself in the rhetoric of Open Source, its introduciton does 
open the door for the IT department to sneak in some real Open Source.  But 
in most cases, Linux opened the door to OSS a while ago.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: [pgsql-advocacy] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T18:13:06Z

On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
> Stephan Szabo wrote:
> 
> >>I know this to be true, but don't fully understand it... if our default
> >>behavior is to fold lower, and we change it to just fold upper... then
> >>in theory this shouldn't break anything since what used to be folder
> >>lower will now simply be folder upper. the only people who will have a
> >>problem are those who quote on one end but not the other, which is bad
> >>practice anyways...  so i would say if your serious about it, make the
> >>patch as GUC "case_folding" for upper or lower and get a taste for what
> >>breaks inside the db.
> >>    
> >>
> >
> >I've tried just changing the parser to unconditionally casefold to upper.
> >First thing that happens is that initdb breaks. In addition, you have
> >potential issues with comparisons against the catalog's versions of
> >standard functions as such if you allow the case folding to be changed
> >after the catalogs are setup.
> >
> >  
> >
> 
> ISTM that rather than a having a GUC setting, initdb would be the right 
> time to make this choice. I'm not saying it would be easy, but it seems 
> (without looking into it deeply) at least possible.
> 

This implies that the standard functions are created with explicit
quoting to make the lower case named?  Shouldn't all functions be
created without any quoting so they fold to whichever way the settings
are set?  Hmm... I see your angle Andrew.. they are going to be created
one way or the other so you'd be hard pressed to do it at any time other
than initdb time... of course you could just create duplicates of all
the functions in both upper and lower case, that way whichever way you
fold it matches :-)

Robert Treat  
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [HACKERS] What can we learn from MySQL?

Chris Browne <cbbrowne@acm.org> — 2004-04-23T18:18:14Z

Martha Stewart called it a Good Thing when pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> D'Arcy J.M. Cain wrote:
>> On Fri, 23 Apr 2004 11:07:20 -0400
>> Dave Cramer <pg@fastcrypt.com> 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?

This is what suggests to me the possibility that perhaps a good
answer would be to redo it in some scripting language, and have the
capability to either:
 a) Configure multiple targets via some language-specific approach
    (e.g. - reading Perl data structures, or some such thing) or
 b) Configure multiple targets via having the configuration stored
    in one database/schema.

I would somewhat favor the latter.

The initial design was set up jointly with a view to 
 a) minimizing the number of extra dependancies, and
 b) ultimately being a stop-gap measure until a _proper_ scheme
    could get integrated into the postmaster.

The existing implementation has remained sufficiently fragile that we
have a hard time trusting it with the _important_ systems, and since
those systems tend to involve multiple backends, it sure would be nice
to have something that could get run across ALL of them, where we
could be confident that it wouldn't demolish I/O at inconvenient times
by trying to simultaneously vacuum huge tables on multiple backends.

I have lately been working on some (not quite yet sufficiently
generic) tools for managing sets of replication instances; I think I
may want to take a similar "tack" on this.  pg_autovacuum has been
handy for systems that I _don't_ want to pay much attention to, but it
hasn't been totally adequate for the more vital ones.
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/linuxdistributions.html
A real  patriot is the fellow  who gets a parking  ticket and rejoices
that the system works.

Re: What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T18:27:59Z

On Fri, 2004-04-23 at 13:13, Bruce Momjian wrote:
> Josh Berkus wrote:
> > This last lesson was really driven home to me at the Open Source Business 
> > Convention; managers were slavering all over "dual licensing" as the "new 
> > model of open source."   When I pointed out that there's another name for 
> > dual licensing -- "shareware" -- I got some real uncomfortable silences.   
> > Seems that a lot of companies want the fruits of Open Source without changing 
> > the way they do business at all.  Big surprise, eh?
> 
> Agreed.  I see dual-license as an interim step for companies moving from
> close to true open source.
> 

Funny, I've never really felt that way. I don't see all that much
difference between what my$ql does with it's database and what m$ did
with ie or office or <insert m$ product here>... give it away for free
until you get enough market share to start charging more and more. I
guess it's a little better because if the company itself we're ever to
go under people could still take the source and go with it, but still
the dual license scheme to me is just the latest incarnation of a
"loss-leader" marketing plan. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [pgsql-advocacy] What can we learn from MySQL?

Andrew Dunstan <andrew@dunslane.net> — 2004-04-23T18:28:10Z

Robert Treat wrote:

>On Fri, 2004-04-23 at 13:11, Andrew Dunstan wrote:
>  
>
>>Stephan Szabo wrote:
>>
>>    
>>
>>>>I know this to be true, but don't fully understand it... if our default
>>>>behavior is to fold lower, and we change it to just fold upper... then
>>>>in theory this shouldn't break anything since what used to be folder
>>>>lower will now simply be folder upper. the only people who will have a
>>>>problem are those who quote on one end but not the other, which is bad
>>>>practice anyways...  so i would say if your serious about it, make the
>>>>patch as GUC "case_folding" for upper or lower and get a taste for what
>>>>breaks inside the db.
>>>>   
>>>>
>>>>        
>>>>
>>>I've tried just changing the parser to unconditionally casefold to upper.
>>>First thing that happens is that initdb breaks. In addition, you have
>>>potential issues with comparisons against the catalog's versions of
>>>standard functions as such if you allow the case folding to be changed
>>>after the catalogs are setup.
>>>
>>> 
>>>
>>>      
>>>
>>ISTM that rather than a having a GUC setting, initdb would be the right 
>>time to make this choice. I'm not saying it would be easy, but it seems 
>>(without looking into it deeply) at least possible.
>>
>>    
>>
>
>This implies that the standard functions are created with explicit
>quoting to make the lower case named?  Shouldn't all functions be
>created without any quoting so they fold to whichever way the settings
>are set?  Hmm... I see your angle Andrew.. they are going to be created
>one way or the other so you'd be hard pressed to do it at any time other
>than initdb time... of course you could just create duplicates of all
>the functions in both upper and lower case, that way whichever way you
>fold it matches :-)
>
>  
>

That strikes me as an instant recipe for shooting yourself in the foot, 
as well as providing useless catalog bloat. Things need *one* canonical 
name, IMNSHO.

cheers

andrew

Re: What can we learn from MySQL?

J. Andrew Rogers <jrogers@neopolitan.com> — 2004-04-23T18:56:42Z

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 solvable
problems.  I think improved default product packaging would remove 80%
of the impediment to more widespread adoption.

There is no *technical* reason things should be done this way and it
might even go against the sensibilities of many current users.  But it
would go a long way toward widening the audience.

j. andrew rogers

Re: [pgsql-advocacy] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T19:02:46Z

On Fri, 2004-04-23 at 12:07, Alexey Borzov wrote:
> Hi!
> 
> Rod Taylor wrote:
> > My present theory is that most users make the decision regarding ease of
> > use before even installing the software.
> > 
> > If you look at the MySQL website within 1 or 2 clicks, you know that
> > there is a gui for queries, a gui for administration, drivers or
> > interfaces for many programming langauges. They have GIS, Unicode, full
> > text searching, multi-master replication, ANSI compliance, etc.
> > 
> > ...
> > 
> > You don't learn anything about the GUIs (any of them) within the first
> > couple of clicks. Since many users (even linux users) associate command
> > lines with difficulty of use, the first impression is that PostgreSQL is
> > difficult to use.
> 
> I think that PostgreSQL's "download" page should point to at least
> * Recommended replication solution (erserver?)
> * Recommended full-text search solution (tsearch?)
> * Recommended GUI / web frontend (PGAdmin / phpPgAdmin)
> * Drivers: ODBC, JDBC, whatever
> * PostGIS
> * Banners to put on the website
> * A description of what to find in the contrib dir
> 
> If someone makes such a page, I'll promptly add it to the 
> "next-generation" site.
> 

Do you think you could mock one up with fake projects and links?  It
would make it easier to wrap our heads around how that would work with
translations and mirroring. 

Robert Treat 
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [pgsql-advocacy] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T19:04:53Z

On Fri, 2004-04-23 at 14:28, Andrew Dunstan wrote:
> Robert Treat wrote:
> of course you could just create duplicates of all
> >the functions in both upper and lower case, that way whichever way you
> >fold it matches :-)
> >
> 
> That strikes me as an instant recipe for shooting yourself in the foot, 
> as well as providing useless catalog bloat. Things need *one* canonical 
> name, IMNSHO.
> 

hence the smiley...

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [pgsql-advocacy] What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-23T19:13:15Z

Folks,

> > * Recommended replication solution (erserver?)
> > * Recommended full-text search solution (tsearch?)
> > * Recommended GUI / web frontend (PGAdmin / phpPgAdmin)
> > * Drivers: ODBC, JDBC, whatever
> > * PostGIS
> > * Banners to put on the website
> > * A description of what to find in the contrib dir

I'm really nervous about pointing to "recommended" solutions where we have 
several.   I'd rather have links to all mature projects in that category.

Replication is actually several different problems demanding several different 
solutions.   So no one replication solution is going to cover all needs, 
ever.

For GUIs, we have an embarassment of them, and I would not want to be 
responsible for telling anyone their project is "not recommended".  That's an 
effective way of making a lot of enemies in the OSS community.   Instead, I 
might suggest listing all OSS GUIs in order of popularity -- which still lets 
PGAdmin & phpPGAdmin float to the top, but without telling Xpg or PGAccess to 
take a flying leap into the void.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: [HACKERS] What can we learn from MySQL?

Jim Nasby <jim@nasby.net> — 2004-04-23T19:27:30Z

On Fri, Apr 23, 2004 at 02:35:48PM +0800, Christopher Kings-Lynne 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.
> >
> >Questions I have are:
> 
> I have already told Bruce at length about the single most common 
> complaint in the phpPgAdmin lists and in the IRC channel: the inability 
> to change column types.  I think we should listen to the punters on that 
> one.
> 
> Also, how about a new section in the manual: PostgreSQL for MySQL users 
> and PostgreSQL for Oracle users?

Maybe also a more generic section about how PGSQL is different from
other databases. Maybe I'm just dense, but it took me a long time to
figure out the whole lack of stored procedures thing (yes, PGSQL
obviously has the functionality, but many experienced DBAs won't
associate functions with stored procs). Pointing out the documentation
on MVCC and how it changes how you want to use the database would be
good, as would links to documentation on what postgresql.conf settings
you want to change out of the box.

On the other topics...
I think the biggest service PGSQL could provide to the open source
community is a resource that teaches people with no database experience
the fundamentals of databases. If people had an understanding of what a
RDBMS should be capable of and how it should be used, they wouldn't pick
MySQL.

Having a windows port is critical for 'student mindshare'. If PGSQL can't
play on windows, professors can't use it. Likewise, installation on OS X
should be made as easy as possible.

That's for the 'low end' users (many of whom will eventually become
'high end'). For professionals who have database expertise, the
comparison guide will help a lot. The other thing that will help is
continuing to bring enterprise-class features in, like multi-master
replication, partitioning, and clustering. But since people tend to
think most about the technology, I'm sure those will make it in
eventually anyway. :)
-- 
Jim C. Nasby, Database Consultant                  jim@nasby.net
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?"

Re: [HACKERS] What can we learn from MySQL?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-23T19:40:33Z

Stephan Szabo wrote:

>I've tried just changing the parser to unconditionally casefold to upper.
>First thing that happens is that initdb breaks. In addition, you have
>potential issues with comparisons against the catalog's versions of
>standard functions as such if you allow the case folding to be changed
>after the catalogs are setup.
>  
>
That's not the migration path I was thinking of.

What I was thinking of was:
1. Have a setting, probably per-session. Per database works too.
2. Aside from the folder upper and folder lower, have a third option. 
This is "fold upper, if fails, fold lower. If succeeds, issue a 
warning". This should allow programs that rely on the folding (such as 
initdb) to be debugged during the transition period.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: [pgsql-advocacy] What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-23T19:50:10Z

Hi!

Robert Treat wrote:
> Do you think you could mock one up with fake projects and links?  It
> would make it easier to wrap our heads around how that would work with
> translations and mirroring. 

Sorry, right now I'm working on admin interface for postgresql.org, then I'll be 
doing static mirror building stuff.

I meant this page will come instead of mirror selection, when the visitor clicks 
on Download. If he decides to download PostgreSQL itself, he will hit the 
current mirror selection page.

Re: What can we learn from MySQL?

Jeff Davis <jdavis-pgsql@empires.org> — 2004-04-23T20:01:02Z

On Fri, 2004-04-23 at 07:13, Fabien COELHO wrote:

> 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.
> 

The debian package automatically makes a vacuum entry in the crontab.
So, to a certain extent, this could be solved at the distribution level.

However, the pg_autovacuum project will be a great improvement over
that. Right now, the distributions mostly care about MySQL, so it will
be nice to have postgresql handle that detail.

Jeff

Re: [pgsql-advocacy] What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-23T20:05:33Z

Hi!

Josh Berkus wrote:
>>>* Recommended replication solution (erserver?)
>>>* Recommended full-text search solution (tsearch?)
>>>* Recommended GUI / web frontend (PGAdmin / phpPgAdmin)
>>>* Drivers: ODBC, JDBC, whatever
>>>* PostGIS
>>>* Banners to put on the website
>>>* A description of what to find in the contrib dir
> 
> I'm really nervous about pointing to "recommended" solutions where we have 
> several.   I'd rather have links to all mature projects in that category.

Okay, s/recommended/mature/

> Replication is actually several different problems demanding several different 
> solutions.   So no one replication solution is going to cover all needs, 
> ever.

Okay, but currently *the* replication solution that's linked from every page of 
postgresql.org is pgreplication. Which is either dead or just stinks like one.

> For GUIs, we have an embarassment of them, and I would not want to be 
> responsible for telling anyone their project is "not recommended".  That's an 
> effective way of making a lot of enemies in the OSS community.   Instead, I 
> might suggest listing all OSS GUIs in order of popularity -- which still lets 
> PGAdmin & phpPGAdmin float to the top, but without telling Xpg or PGAccess to 
> take a flying leap into the void.

Who will define "popularity"?

Of course, it is possible to just create a page for all the GUIs, but it will 
require discipline or else it will degenerate to
http://www.postgresql.org/users-lounge/related.html
or
http://www.postgresql.org/users-lounge/interfaces.html

Re: [HACKERS] What can we learn from MySQL?

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-23T20:16:15Z

On Fri, 23 Apr 2004, Shachar Shemesh wrote:

> Stephan Szabo wrote:
>
> >I've tried just changing the parser to unconditionally casefold to upper.
> >First thing that happens is that initdb breaks. In addition, you have
> >potential issues with comparisons against the catalog's versions of
> >standard functions as such if you allow the case folding to be changed
> >after the catalogs are setup.
> >
> >
> That's not the migration path I was thinking of.
>
> What I was thinking of was:
> 1. Have a setting, probably per-session. Per database works too.
> 2. Aside from the folder upper and folder lower, have a third option.
> This is "fold upper, if fails, fold lower. If succeeds, issue a
> warning". This should allow programs that rely on the folding (such as
> initdb) to be debugged during the transition period.

If you can do this in a clean fashion without tromping all around the
code, that'd be reasonable, however, istm that you'd need to either
pre-fold both directions from the given identifier string and pass an
extra copy around or pass the original identifier and its quoted status
and fold on use.  I think either of these are likely to be very intrusive
for what essentially amounts to a transitional feature.

In addition, I'm not sure that this would always work in any case, since
some of those usages may be quoted identifiers that were once generated
from a case-folded string (for example, looking up a name in the catalogs
and quoting it).

Re: [pgsql-advocacy] What can we learn from MySQL?

Rod Taylor <pg@rbt.ca> — 2004-04-23T20:28:04Z

Forgive my crappy HTML. But this is along the lines of what I was
thinking.

> Do you think you could mock one up with fake projects and links?  It
> would make it easier to wrap our heads around how that would work with
> translations and mirroring.

Re: [HACKERS] What can we learn from MySQL?

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-23T20:31:16Z

On Fri, 23 Apr 2004, Stephan Szabo wrote:

> On Fri, 23 Apr 2004, Shachar Shemesh wrote:
>
> > Stephan Szabo wrote:
> >
> > >I've tried just changing the parser to unconditionally casefold to upper.
> > >First thing that happens is that initdb breaks. In addition, you have
> > >potential issues with comparisons against the catalog's versions of
> > >standard functions as such if you allow the case folding to be changed
> > >after the catalogs are setup.
> > >
> > >
> > That's not the migration path I was thinking of.
> >
> > What I was thinking of was:
> > 1. Have a setting, probably per-session. Per database works too.
> > 2. Aside from the folder upper and folder lower, have a third option.
> > This is "fold upper, if fails, fold lower. If succeeds, issue a
> > warning". This should allow programs that rely on the folding (such as
> > initdb) to be debugged during the transition period.
>
> If you can do this in a clean fashion without tromping all around the
> code, that'd be reasonable, however, istm that you'd need to either
> pre-fold both directions from the given identifier string and pass an
> extra copy around or pass the original identifier and its quoted status
> and fold on use.  I think either of these are likely to be very intrusive
> for what essentially amounts to a transitional feature.
>
> In addition, I'm not sure that this would always work in any case, since
> some of those usages may be quoted identifiers that were once generated
> from a case-folded string (for example, looking up a name in the catalogs
> and quoting it).

To clarify, I'm thinking about things where an application had gotten a
quoted name and is now trying to use it where the object's canonical name
was changed due to quoting changes. This only happens when quoting
is inconsistently applied, but that's most of the problem.

Re: [HACKERS] What can we learn from MySQL?

Mark Woodward <pgsql@mohawksoft.com> — 2004-04-23T20:36:57Z

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."

Re: [HACKERS] What can we learn from MySQL?

Alvar Freude <alvar@a-blast.org> — 2004-04-23T20:43:09Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

- -- Bruce Momjian <pgman@candle.pha.pa.us> 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 500000 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-----

Re: [HACKERS] What can we learn from MySQL?

Alvar Freude <alvar@a-blast.org> — 2004-04-23T21:14:17Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

- -- pgsql@mohawksoft.com 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 100000 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=1&msg_id=5487088&forum_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-----

Re: What can we learn from MySQL?

Peter Eisentraut <peter_e@gmx.net> — 2004-04-23T22:31:13Z

Alexey Borzov wrote:
> I think that PostgreSQL's "download" page should point to at least
> * Recommended replication solution (erserver?)
> * Recommended full-text search solution (tsearch?)
> * Recommended GUI / web frontend (PGAdmin / phpPgAdmin)
> * Drivers: ODBC, JDBC, whatever
> * PostGIS
> * Banners to put on the website
> * A description of what to find in the contrib dir

A couple of months ago I grew tired of having to find all the PostgreSQL 
pieces all over the net, plus having to get them to get along with each 
other and the rest of the system.  So I started packaging and 
collecting them here: <http://www.unitedpostgresql.org/>.  It's already 
saved me a bunch of time.  Feel free to take from it.

Re: [pgsql-advocacy] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T23:55:16Z

On Friday 23 April 2004 16:05, Alexey Borzov wrote:
> Josh Berkus wrote:
> >
> > I'm really nervous about pointing to "recommended" solutions where we
> > have several.   I'd rather have links to all mature projects in that
> > category.
>
> Okay, s/recommended/mature/
>

good suggestion. 

> > Replication is actually several different problems demanding several
> > different solutions.   So no one replication solution is going to cover
> > all needs, ever.
>
> Okay, but currently *the* replication solution that's linked from every
> page of postgresql.org is pgreplication. Which is either dead or just
> stinks like one.
>
> > For GUIs, we have an embarassment of them, and I would not want to be
> > responsible for telling anyone their project is "not recommended". 
> > That's an effective way of making a lot of enemies in the OSS community. 
> >  Instead, I might suggest listing all OSS GUIs in order of popularity --
> > which still lets PGAdmin & phpPGAdmin float to the top, but without
> > telling Xpg or PGAccess to take a flying leap into the void.
>

josh, did you see... rod taylor i think... post in advocacy about criteria for 
such a page. the first 6 seemed pretty good. 

> Who will define "popularity"?
>
> Of course, it is possible to just create a page for all the GUIs, but it
> will require discipline or else it will degenerate to
> http://www.postgresql.org/users-lounge/related.html
> or
> http://www.postgresql.org/users-lounge/interfaces.html

you mean like http://techdocs.postgresql.org/guides/GUITools ?

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: [HACKERS] What can we learn from MySQL?

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-24T04:11:16Z

Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> To clarify, I'm thinking about things where an application had gotten a
> quoted name and is now trying to use it where the object's canonical name
> was changed due to quoting changes. This only happens when quoting
> is inconsistently applied, but that's most of the problem.

Actually, that's *all* the problem, at least as far as SQL commands are
concerned.  If you are consistent about always quoting or never quoting
a particular name, you can't tell the difference between PG's behavior
and SQL-spec behavior.

Aside from the reality that apps aren't very consistent about their
quoting behavior, the fly in this ointment is that whenever you query
the database catalogs you will see the stored spelling of the name.
So apps that rely on seeing the same spelling in the catalog that they
entered could break.  (In practice this doesn't seem to be as big a
problem as the sloppy-quoting-behavior issue, though.)

Personally I don't think that this is a "transitional issue" and we will
someday all be happy in upper-case-only-land.  Upper-case-only sucks,
by every known measure of readability, and I don't want to have to put up
with a database that forces that 1960s-vintage-hardware mindset on me.
So what I'm holding out for is a design that lets me continue to see the
current behavior if I set a GUC variable that says that's what I want.
This seems possible (not easy, but possible) if we are willing to
require the choice to be made at compile time ... but that sounds too
restrictive to satisfy anybody ... what we need is a design that
supports such a choice per-session, and I dunno how to do that.

			regards, tom lane

PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
to make the point about readability.  But if you want to argue the
point with me, I'll be happy to do that for the rest of the thread.

Re: [HACKERS] What can we learn from MySQL?

Dennis Björklund <db@zigo.dhs.org> — 2004-04-24T04:38:58Z

On Sat, 24 Apr 2004, Tom Lane wrote:

> Upper-case-only sucks, by every known measure of readability, and I
> don't want to have to put up with a database that forces that
> 1960s-vintage-hardware mindset on me.

Well, get used to it :-)

> So what I'm holding out for is a design that lets me continue to see the
> current behavior if I set a GUC variable that says that's what I want.

Wouldn't the upper case identifiers just be visible in the \d output,
table headers and such. You could still have psql tab completion produce
lower case identifiers (if told using some setting).

Even if the database store all non quoted names as upper case I would 
still use lower case in all applications and on the psql command line.

It's not a big problem for me if the output of \d and the table headers
and such is in upper case. One would get used to it fase. And maybe one
can even store an extra bit telling if the string was created with or
without quotes and have psql lower case all the ones created without
quotes.

First I thought that one can store the string with case all the time, and
just convert when needed (when comparing identifiers). Perhaps using the
non existant locale support and locales such as SQL_UPPER or SQL_MIXED.
But it wont work since it would make "Foo" and Foo clash. When translated
directly it would create separate entries "Foo" and "FOO".

ps. And if you want to play the WRITE MAILS USING ONLY UPPER CASE, BE MY 
GUEST!

-- 
/Dennis Björklund

Do we prefer software that works or software that looks good?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-24T05:23:57Z

Tom Lane wrote:

>Personally I don't think that this is a "transitional issue" and we will
>someday all be happy in upper-case-only-land.  Upper-case-only sucks,
>by every known measure of readability, and I don't want to have to put up
>with a database that forces that 1960s-vintage-hardware mindset on me.
>  
>
And I was feeling apologetic that I was accusing without a base the good 
(and I'm not cynical about that last adjective) people of the PostgreSQL 
of making life more difficult for programmers just because they don't 
like the asthetics of something which an external standard dictates.

I mean, sure, I understand the sentiment. I don't like seeing all-caps 
either. But allow me to give an allegory from another free software 
project, one where I am an actual active code contributer.

Imagine that Alexandre Juliard, the benevolent dictator for the Wine 
project, would have had the same attitude. Each time someone would come 
around saying "today function X calls function Y, and this breaks 
program Z. We need to reverse X and Y", he would reply with "But it 
makes more asthetic/program design/whatever sense to do it the way we do 
it today". The result would be that Wine would never come to the point 
where it can run Word, IE and other prominant Windows only applications.

The reality of things is that Wine, just like Postgres, work by an 
external standard. Wine's standard is more strict, less documented, and 
more broad. However, like it or not, the more you deviate from the 
standard, the more you require people who want to use your technology to 
adapt to whatever it is that you do.

This doesn't make sense on any level.

>So what I'm holding out for is a design that lets me continue to see the
>current behavior if I set a GUC variable that says that's what I want.
>  
>
>This seems possible (not easy, but possible) if we are willing to
>require the choice to be made at compile time ... but that sounds too
>restrictive to satisfy anybody ... what we need is a design that
>supports such a choice per-session, and I dunno how to do that.
>  
>
In other words, you are going to reject the simpler solutions that treat 
this as a transition problem, because of asthetic issue? Not even 
program design issue, mind you. Sounds strange to me, and also pretty 
much guarentees that this will never happen. That would be a shame.

The reason this would be a shame is because postgres is the same reason 
this thread was CCed to advocacy to begin with. Databases form a pretty 
saturated field. If Postgres is to break forward, it needs a niche. The 
fully-featured databases role is taken (Oracle), and the free database 
role is taken (MySQL). Postgres CAN take the fuly featured free database 
niche, but that will need help.

The time is ripe, however. The company we're doing my current OLE DB 
work for has contacted me about this, and they dictated Postgres (MySQL 
was not nearly enough). They still want to see proof of concept working, 
but that's my job. However, I'm afraid they might give up if things 
become too complicated to port. Under such circumstances, every little 
help Postgres can give may mean the difference between "breaking 
through" and "staying behind". I really wouldn't like to see such an 
important help break merely because "Tom Lane doesn't like to see 
uppercase on his database tables list".

Now, I'm intending to do the best I can on my end. This does have a 
pretty heavy cost. It means that the OLE DB driver will parse in details 
each query, and perform replacements on the query text. This is bug 
prone, difficult, hurts performance, and just plain wrong from a 
software design perspective. The current drift of wind, however, means 
that the PostgreSQL steering commite seems to prefer having a lesser 
quality driver to seeing ugly uppercase.

>			regards, tom lane
>
>PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
>to make the point about readability.  But if you want to argue the
>point with me, I'll be happy to do that for the rest of the thread.
>  
>
Yes, it's a well known rhetoric technique. Take whatever argument your 
opponent say, and exagerate it to an absurd.

       Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: [HACKERS] What can we learn from MySQL?

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-24T05:47:07Z

Dennis Bjorklund <db@zigo.dhs.org> writes:
> On Sat, 24 Apr 2004, Tom Lane wrote:
>> So what I'm holding out for is a design that lets me continue to see the
>> current behavior if I set a GUC variable that says that's what I want.

> Wouldn't the upper case identifiers just be visible in the \d output,
> table headers and such.

Exactly ... and that's where my readability complaint starts ...

> First I thought that one can store the string with case all the time, and
> just convert when needed (when comparing identifiers).

People keep suggesting these random not-quite-standard behaviors, but
I fail to see the point.  Are you arguing for exact standards
compliance, or not?  If you're not, then you have to make your case on
the claim that "my nonstandard behavior is better than the existing
nonstandard behavior".  Which might be true, beauty being in the eye of
the beholder, but I doubt you can prove it to the extent of overriding
the backwards-compatibility issue.

			regards, tom lane

Re: [HACKERS] What can we learn from MySQL?

Dennis Björklund <db@zigo.dhs.org> — 2004-04-24T05:52:13Z

On Sat, 24 Apr 2004, Tom Lane wrote:

> > First I thought that one can store the string with case all the time, and
> > just convert when needed (when comparing identifiers).
> 
> People keep suggesting these random not-quite-standard behaviors, but
> I fail to see the point.  Are you arguing for exact standards
> compliance, or not? 

That was me making conversation, pointing out something that does not 
work. Since it does not work I don't want it to be implemented. And with 
work I mean not follow the standard.

For something to follow standard it has to behave the correct way to the 
outside, how it's implemented is a different matter. The above does not 
work. Period.

-- 
/Dennis Björklund

Re: [HACKERS] What can we learn from MySQL?

Joe Conway <mail@joeconway.com> — 2004-04-24T05:56:43Z

Tom Lane wrote:
> Aside from the reality that apps aren't very consistent about their
> quoting behavior, the fly in this ointment is that whenever you query
> the database catalogs you will see the stored spelling of the name.
> So apps that rely on seeing the same spelling in the catalog that they
> entered could break.  (In practice this doesn't seem to be as big a
> problem as the sloppy-quoting-behavior issue, though.)

Shouldn't apps only really be querying the information schema if they're 
expecting spec compliant behavior? If so, a GUC variable with an access 
function ought to be enough to get up or down casing as desired, I'd think.

Joe

Re: Do we prefer software that works or software that looks good?

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-24T07:43:25Z

On Sat, 24 Apr 2004, Shachar Shemesh wrote:

> Tom Lane wrote:
> >So what I'm holding out for is a design that lets me continue to see the
> >current behavior if I set a GUC variable that says that's what I want.
> >
> >This seems possible (not easy, but possible) if we are willing to
> >require the choice to be made at compile time ... but that sounds too
> >restrictive to satisfy anybody ... what we need is a design that
> >supports such a choice per-session, and I dunno how to do that.
> >
> >
> In other words, you are going to reject the simpler solutions that treat
> this as a transition problem, because of asthetic issue? Not even
> program design issue, mind you. Sounds strange to me, and also pretty
> much guarentees that this will never happen. That would be a shame.

[ Tom, we know your opinion on the first part of the next paragraph, so
you don't need to reply to that part. ;) ]

Are we going to get rid of the current behavior entirely? If so, how are
we going to handle issues like current databases with names like foo and
"FOO" (and what if the name was given as "foo")? If not, when can one set
the folding options and how do we (in the long term) make the database
work properly in both settings. Things like "don't worry about the catalog
entries" don't fly when your standard functions are defined and
looked up there.

Depending on the answers to the above, we need to think about things like
the transitional plans put forth. Do these plans actually help transition
things. The fold up and down compare one then the other on a failure of
the first may be fairly invasive changes, still has problems when quotes
are used inconsistently and can also silently change behavior from old
versions (on that database mentioned above, what does select * from foo
do, is it the same as before?). These may or may not be huge issues and it
may or may not be easily solvable, but these things need to be figured out
IMHO before something can be considered a solution.

Re: Do we prefer software that works or software that looks good?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-24T08:44:53Z

Stephan Szabo wrote:

>[ Tom, we know your opinion on the first part of the next paragraph, so
>you don't need to reply to that part. ;) ]
>
>Are we going to get rid of the current behavior entirely?
>
I doubt that will be a good idea. You want to let applications created 
for previous versions of PostgreSQL continue to work. The idea, I think, 
is to have either a DB wide, or a session wide, option to have it either 
way. We may have to create a DB conversion tool, that converts a DB from 
one way to the other (and changes the case of functions, along the way).

> If so, how are
>we going to handle issues like current databases with names like foo and
>"FOO" (and what if the name was given as "foo")?
>
I think these are really rare. The conversion tool can warn about these 
cases.

> If not, when can one set
>the folding options and how do we (in the long term) make the database
>work properly in both settings.
>
I don't think having the same DB work in both folding options is really 
a big issue. Having two databases on the same server, one this way and 
one the other is, however. You don't want to install two database 
servers, merely because you have two applications developed for two 
different PG versions.

> Things like "don't worry about the catalog
>entries" don't fly when your standard functions are defined and
>looked up there.
>  
>
Answer above.

>Depending on the answers to the above, we need to think about things like
>the transitional plans put forth. Do these plans actually help transition
>things.
>
I think they do. The idea is to be as complaining and as verbose during 
transition as possible. Ideally, if some breakpoint can be triggered 
each time a double lookup takes place (thus knowing that the client app 
is calling the wrong way), this will allow converting apps in almost no 
time at all.

> The fold up and down compare one then the other on a failure of
>the first may be fairly invasive changes,
>
In what way invasive?

> still has problems when quotes
>are used inconsistently
>
The main issue, as far as I'm concerned, is not with PG apps that need 
to be ported to the new scheme. I don't have any qualm with never 
deprecating the lowercase folding. This, of course, puts a burden on 
utilities that work as infrastructure to always quote or always 
not-quote (depending on exact semantics), but that, I believe, is solveable.

My problem is with applications written for other, more standard 
complient, databases, and with porting these into PG. As such, if the 
app uses inconsistent quoting, it today relies on uppercase folding, and 
will not have any problem.

> and can also silently change behavior from old
>versions (on that database mentioned above, what does select * from foo
>do, is it the same as before?). These may or may not be huge issues and it
>may or may not be easily solvable, but these things need to be figured out
>IMHO before something can be considered a solution.
>  
>
I agree. It's just that I don't think this is a big issue, given the 
fact that I don't think we intend to deprecate the lowercase folding any 
time soon.

          Shachar

Remove advocacy from the CC. I don't think it's related there any more.

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: Do we prefer software that works or software that looks good?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-24T11:48:18Z

On Saturday 24 April 2004 01:23, Shachar Shemesh wrote:
> Tom Lane wrote:
> >PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
> >to make the point about readability.  But if you want to argue the
> >point with me, I'll be happy to do that for the rest of the thread.
>
> Yes, it's a well known rhetoric technique. Take whatever argument your
> opponent say, and exagerate it to an absurd.
>

Kind of like changing the subject line of a thread to imply your side of the 
argument is the one that has technical merit and the other side is being 
petty and/or frivolous?   Anyone who has studied software useability will 
know that uppercase should, in general, be avoided as it hurts readability. 
It isn't about "looking pretty", it's about being more usable.  

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: Do we prefer software that works or software that looks good?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-24T12:09:51Z

Robert Treat wrote:

>On Saturday 24 April 2004 01:23, Shachar Shemesh wrote:
>  
>
>>Tom Lane wrote:
>>    
>>
>>>PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
>>>to make the point about readability.  But if you want to argue the
>>>point with me, I'll be happy to do that for the rest of the thread.
>>>      
>>>
>>Yes, it's a well known rhetoric technique. Take whatever argument your
>>opponent say, and exagerate it to an absurd.
>>
>>    
>>
>
>Kind of like changing the subject line of a thread to imply your side of the 
>argument is the one that has technical merit and the other side is being 
>petty and/or frivolous?
>
It is my understanding that the discussion with Tom was 100% about the 
question in the subject line. There is no question that the SQL standard 
dictates that unquoted identifiers should be folded to uppercase. There 
is no question (not from me) that upper case is ugly. The only question 
is whether we should prefer standard to asthetic.

>   Anyone who has studied software useability will 
>know that uppercase should, in general, be avoided as it hurts readability. 
>  
>
You convinced me! let's change the SQL standard.

>It isn't about "looking pretty", it's about being more usable.  
>
>Robert Treat
>  
>
Ok. I'm willing to change the subject to "are hurting eyes due to 
uppercase preferable to changing lots of code when migrating to PG from 
other database due to standard incomplience", if it would make you feel 
better.

The point is that I am not against lower case, or pro uppercase. I HATE 
uppercase. I do think, however, that standards should be followed. The 
question is, when all is said and done, which is more useable. A DB that 
presents unquoted identifiers as uppercase, or one that allows easier 
migration of client apps from other DBs.

I'll also mention that if asthetic/readability is all that bothers you, 
we can add a flag to psql that displays all caps as lowercase.

          Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: Do we prefer software that works or software that looks good?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-24T13:09:46Z

On Saturday 24 April 2004 08:09, Shachar Shemesh wrote:
> Robert Treat wrote:
> >   Anyone who has studied software useability will
> >know that uppercase should, in general, be avoided as it hurts
> > readability.
>
> You convinced me! let's change the SQL standard.
>

We plan to, right after we have PostgreSQL achieve world domination. But we 
can't abondon lower case now or it will weaken the argument when that time 
comes. :-)

>
> Ok. I'm willing to change the subject to "are hurting eyes due to
> uppercase preferable to changing lots of code when migrating to PG from
> other database due to standard incomplience", if it would make you feel
> better.
>

ouch.  s/code when/code from crappily written apps when/    :-)

> The point is that I am not against lower case, or pro uppercase. I HATE
> uppercase. I do think, however, that standards should be followed. The
> question is, when all is said and done, which is more useable. A DB that
> presents unquoted identifiers as uppercase, or one that allows easier
> migration of client apps from other DBs.
>

IMHO apps that apply quoted identifiers willy nilly are busted anyway, and it 
is only by coincidence that they work on other databases if they work at all.  
(And it's by extremely unfortunate coincidence that they might be spec 
complient in that behavior.. but hey.)    

Oh well... let's see if we can find a way to support both... 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: Do we prefer software that works or software that looks good?

Shachar Shemesh <psql@shemesh.biz> — 2004-04-24T13:21:54Z

Robert Treat wrote:

>IMHO apps that apply quoted identifiers willy nilly are busted anyway,
>
Not really. Sometimes the app itself will be very consistent, never 
applying quotes, but an underlying driver will always apply quotes. The 
result is a mixed behaviour. There is nothing you or me can do about 
that. Notice that in the above case, neither app nor driver are 
violating their mandate, and both are well within their right to do so.

So long as the behaviour is regulated by a standard, there is nothing 
you and I can say against such practices.

>Oh well... let's see if we can find a way to support both... 
>
>  
>
You are welcome to join the other leg of this thread, then. That one is 
not CCed to advocacy, as it is 100% technical.

>Robert Treat
>  
>
    Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: [pgsql-advocacy] What can we learn from MySQL?

Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-04-24T15:40:22Z

On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote:
> Tom Lane wrote:
> >Aside from the reality that apps aren't very consistent about their
> >quoting behavior, the fly in this ointment is that whenever you query
> >the database catalogs you will see the stored spelling of the name.
> >So apps that rely on seeing the same spelling in the catalog that they
> >entered could break.  (In practice this doesn't seem to be as big a
> >problem as the sloppy-quoting-behavior issue, though.)
> 
> Shouldn't apps only really be querying the information schema if they're 
> expecting spec compliant behavior? If so, a GUC variable with an access 
> function ought to be enough to get up or down casing as desired, I'd think.

Some questions:

Is there a way to make this work?  At what level should the current
system be modified?  If the parser or lexer is to be modified, are they
going to need database access?  They are not allowed to, AFAIR.

One could invent a GUC setting for this, and have it set at database
creation time.  How would shared catalogs be handled?  Should we have a
template database for uppercase and another one for lower case
databases?  Should non-shared catalogs be handled in a special way?

Or maybe it is a compilation switch.  What issues would arise?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Before you were born your parents weren't as boring as they are now. They
got that way paying your bills, cleaning up your room and listening to you
tell them how idealistic you are."  -- Charles J. Sykes' advice to teenagers

Re: Do we prefer software that works or software that looks good?

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-24T16:11:47Z

On Sat, 24 Apr 2004, Shachar Shemesh wrote:

> Stephan Szabo wrote:
>
> >Are we going to get rid of the current behavior entirely?
> >
> I doubt that will be a good idea. You want to let applications created
> for previous versions of PostgreSQL continue to work. The idea, I think,
> is to have either a DB wide, or a session wide, option to have it either
> way. We may have to create a DB conversion tool, that converts a DB from
> one way to the other (and changes the case of functions, along the way).

I'm going to assume that we're making the assumption that the user isn't
going to try to do this on databases where it doesn't work? I think we've
lost any information about quoting (was that named "foo" or foo?) so I
don't think we can meaningfully make a current PostgreSQL app that's
inconsistent about quoting work after the conversion. I think this is
reasonable, but others may disagree.

> > If so, how are
> >we going to handle issues like current databases with names like foo and
> >"FOO" (and what if the name was given as "foo")?
> >
> I think these are really rare. The conversion tool can warn about these
> cases.

I agree, but we need to think about these cases (and any other wacky cases
like this) so that we can warn about these cases rather than just not
handle them.

> > If not, when can one set
> >the folding options and how do we (in the long term) make the database
> >work properly in both settings.
> >
> I don't think having the same DB work in both folding options is really
> a big issue. Having two databases on the same server, one this way and
> one the other is, however. You don't want to install two database
> servers, merely because you have two applications developed for two
> different PG versions.

To be honest for me, it really doesn't feel much different than an app
written for 7.2 and one written for 7.4 where the former uses things that
were removed and so cannot be moved to 7.4 without changes. But that's
just an option.

> > Things like "don't worry about the catalog
> >entries" don't fly when your standard functions are defined and
> >looked up there.
> >
> >
> Answer above.

Okay, under that world view (as opposed to on the fly), I think the only
issues come in from shared catalogs, most importantly user names.  This is
certainly solvable, but we need to consider how we handle them when given
to commands like ALTER USER or CREATE USER.

> > The fold up and down compare one then the other on a failure of the
> >first may be fairly invasive changes,
> >
> In what way invasive?

Right now AFAIK most of the case folding stuff pretty much happens in one
place during normal queries and the identifier string you get out has the
post-folding identifier for unquoted or the contained literal for quoted.

In a system where you fold both directions, I can see a few
obvious options:
 a) keep around the real identifier that was given plus whether or
   not it was quoted.
 b) keep around both folded identifiers (for non-quoted names).
 c) fold one direction then the other.  This may potentially do the
    wrong thing in some locales

I don't know how you were planning to handle this issue so I don't know if
any of these scenarios were what you were thinking of or if you had a
better idea.  I think all of these potentially may need to touch at least
some places where the identifier is used and I think all of them need
information that is not AFAIK currently returned from scan.l which means
passing that information along (which may change stuff along the way).

> > still has problems when quotes
> >are used inconsistently
> >
> The main issue, as far as I'm concerned, is not with PG apps that need
> to be ported to the new scheme. I don't have any qualm with never
> deprecating the lowercase folding. This, of course, puts a burden on
> utilities that work as infrastructure to always quote or always
> not-quote (depending on exact semantics), but that, I believe, is solveable.
>
> My problem is with applications written for other, more standard
> complient, databases, and with porting these into PG. As such, if the
> app uses inconsistent quoting, it today relies on uppercase folding, and
> will not have any problem.

That sounds like a plus for having the option for full uppercase folding.
I have no problems with that (I wouldn't have even looked at initdb if I
didn't want to give an option for uppercase folding) but I'm not convinced
it actually is a plus for the transitional setting. An app written for
full uppercase should work in said option without needing the transitional
setting and in fact the transitional setting might do the wrong thing for
said application. The only place I can see transitional being useful is
for upgrading and testing our own stuff (make the server work, make
pg_dump work, etc) and for applications moving from supporting only the
lowercase to supporting both or only upper. For the former, it doesn't
need to be a truly supported feature if it's going in in a single version,
and for the latter, I think as many of the wierd change and such issues as
possible are important and need to be considered if only for documentation
purposes.

Re: [HACKERS] What can we learn from MySQL?

Bruno Wolff III <bruno@wolff.to> — 2004-04-24T17:10:01Z

On Fri, Apr 23, 2004 at 16:36:57 -0400,
  pgsql@mohawksoft.com 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.

Re: [HACKERS] What can we learn from MySQL?

Andrew Sullivan <ajs@crankycanuck.ca> — 2004-04-24T17:46:41Z

On Fri, Apr 23, 2004 at 11:45:28AM -0400, Robert Treat wrote:

> lower will now simply be folder upper. the only people who will have a
> problem are those who quote on one end but not the other, which is bad
> practice anyways...  so i would say if your serious about it, make the
> patch as GUC "case_folding" for upper or lower and get a taste for what
> breaks inside the db. 

If it were that easy, it wouldn't matter, right?  That is, if you had
a system which was either consistently quoted or consistently
unquoted, then you'd never run into the problem of the upper-or-lower
question.

It's precisely _because_ systems often have been maintained by
various cranks for 20 years that it's a problem.  One guy thinks
quoting is stupid.  Another thinks that if you don't quote, you're
asking for trouble,  A third has been rigourous in following the
quoting convention he learned in his last job.  The ship date is
three weeks away, and there are 802 "P1" bugs filed.  What chance do
you think there is that someone is going to scrub all the checkins of
quotes (or apply them carefully)?  This is _exactly_ why standards
compliance for this stuff matters, and why backward comaptibility is
also a top priority.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca

Re: [HACKERS] What can we learn from MySQL?

Jordan Henderson <jordan_henders@yahoo.com> — 2004-04-24T19:05:06Z

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 <bruno@wolff.to> wrote:
> On Fri, Apr 23, 2004 at 16:36:57 -0400,
>   pgsql@mohawksoft.com 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?

Chris Travers <chris@metatrontech.com> — 2004-04-24T22:08:59Z

Bruno Wolff III wrote:

>On Fri, Apr 23, 2004 at 16:36:57 -0400,
>  pgsql@mohawksoft.com 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.
>
>  
>
I second that.  I have not found *anybody* who has used Oracle's 
installer to install the actual database server on Linux or Solaris who 
has described their installation proceedure as either "nice" or "easy."  
In fact even reading the installation isntructions is enough to give you 
second thoughts....  MS SQL does have a nice installer, however, as do 
most binary open source products for Windows.  I am completely confident 
that PostgreSQL for Windows, when it arrives, will have a nice GUI-based 
installer.

Best Wishes,
Chris Travers
Metatron Technology Consulting

Re: Do we prefer software that works or software that looks good?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-24T22:53:16Z

On Saturday 24 April 2004 09:21, Shachar Shemesh wrote:
> Robert Treat wrote:
> >Oh well... let's see if we can find a way to support both...
>
> You are welcome to join the other leg of this thread, then. That one is
> not CCed to advocacy, as it is 100% technical.
>

I'm already there...

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: Do we prefer software that works or software that

Stephan Szabo <sszabo@megazone.bigpanda.com> — 2004-04-25T05:50:11Z

On Sat, 24 Apr 2004, Stephan Szabo wrote:

> On Sat, 24 Apr 2004, Shachar Shemesh wrote:
>
> > Stephan Szabo wrote:
>
> > > Things like "don't worry about the catalog
> > >entries" don't fly when your standard functions are defined and
> > >looked up there.
> > >
> > >
> > Answer above.
>
> Okay, under that world view (as opposed to on the fly), I think the only
> issues come in from shared catalogs, most importantly user names.  This is

In fact the above is incomplete.  You also need to be able to do the right
thing when creating a database with a different setting than its template
database. I'm not really sure how to define "right thing" however if
things have been added to the template db.

Re: [HACKERS] What can we learn from MySQL?

Rob <pgadmin@itsbeen.sent.com> — 2004-04-25T13:55:27Z

Bruno Wolff III wrote:

> On Fri, Apr 23, 2004 at 16:36:57 -0400,
>   pgsql@mohawksoft.com 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.

I have to agree, I've installed DB2, Sybase, Oracle, Informix, 
BerkeleyDB, mySQL, postgreSQL and others.

IIRC, I believe postgreSQL was the shortest from download to running 
system (when compiling the OS ones from scratch) and seemed to do the 
most thorough testing of itself.

Oracle doesn't seem to give you the option to not install the hundreds 
of megs of documentation on the Nth machine where you just needed the 
damn client lib - less of an issue now than in the smaller 
disk/partition days.

But I think there is room to go further, I don't see any reason why that 
default install can't include example DBs, sample maintenance scripts, 
etc. One nice thing to have would be a sample DB with the scripts 
necessary to spin up a test/demo DB with a size of X megs. Whenever I 
started with a new DB system, I wished I didn't have to ramp up on a 
bunch of topics before I was able to build a set of scripts to generate 
and populate a sizable testing db. There is a big psychological factor 
if you can install something, type one command and have a db with 
250,000 records to start playing with.

Re: [HACKERS] What can we learn from MySQL?

Peter Eisentraut <peter_e@gmx.net> — 2004-04-25T14:22:28Z

Rob wrote:
> But I think there is room to go further, I don't see any reason why
> that default install can't include example DBs,

One reason is that a useful example database would likely have a 
download footprint of 10 MB or more.  Having this in the default 
download would not be appreciated by many people.  Of course having 
some example database available at all would be a good idea, but then 
as a separate download.

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-25T20:41:27Z

Peter Eisentraut wrote:
> Rob wrote:
> > But I think there is room to go further, I don't see any reason why
> > that default install can't include example DBs,
> 
> One reason is that a useful example database would likely have a 
> download footprint of 10 MB or more.  Having this in the default 
> download would not be appreciated by many people.  Of course having 
> some example database available at all would be a good idea, but then 
> as a separate download.

Here is a little psql script I wrote to populate a table with random
data.

-- 
  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

Re: [HACKERS] What can we learn from MySQL?

Rob <pgadmin@itsbeen.sent.com> — 2004-04-25T21:29:11Z

Bruce Momjian wrote:

> Peter Eisentraut wrote:
> 
>>Rob wrote:
>>
>>>But I think there is room to go further, I don't see any reason why
>>>that default install can't include example DBs,
>>
>>One reason is that a useful example database would likely have a 
>>download footprint of 10 MB or more.  Having this in the default 
>>download would not be appreciated by many people.  Of course having 
>>some example database available at all would be a good idea, but then 
>>as a separate download.
> 
> 
> Here is a little psql script I wrote to populate a table with random
> data.
[snip]

Right, I have done the same in the past using random character data (it 
even had random lengths of strings in the different fields) and in other 
cases random dictionary words. I was thinking something with more 
structure, like an customer/product/invoice db with random records that 
link up to each other properly.

I will work on something but am wondering if there are any freely 
available schemas around (for any system, I know Sybase has a book 
publishing one that they use in their example queries and is provided 
with their install, "pubs2" I believe) that might be good for use in a 
more extended sample db.

Are there any platforms (outside of MS Windows) that don't include a 
word list or dictionary these days?

Re: Do we prefer software that works or software that looks good?

Josh Berkus <josh@agliodbs.com> — 2004-04-26T17:16:07Z

Shachar,

> Now, I'm intending to do the best I can on my end. This does have a
> pretty heavy cost. It means that the OLE DB driver will parse in details
> each query, and perform replacements on the query text. This is bug
> prone, difficult, hurts performance, and just plain wrong from a
> software design perspective. The current drift of wind, however, means
> that the PostgreSQL steering commite seems to prefer having a lesser
> quality driver to seeing ugly uppercase.

Hey, now wait a minute.   As far as I can tell, you've heard only from Tom 
Lane on the steering committee (I may have missed some, though, I've been 
sick)   Unless the 5 of us take a vote, Tom Lane speaks for Tom Lane, not for 
Core.    Also, usually this list or Patches determines by consensus what gets 
in; the Core only gets involved in very unusual cases.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

Re: Do we prefer software that works or software

Shachar Shemesh <psql@shemesh.biz> — 2004-04-26T17:20:15Z

Josh Berkus wrote:

>Shachar,
>
>  
>
>>Now, I'm intending to do the best I can on my end. This does have a
>>pretty heavy cost. It means that the OLE DB driver will parse in details
>>each query, and perform replacements on the query text. This is bug
>>prone, difficult, hurts performance, and just plain wrong from a
>>software design perspective. The current drift of wind, however, means
>>that the PostgreSQL steering commite seems to prefer having a lesser
>>quality driver to seeing ugly uppercase.
>>    
>>
>
>Hey, now wait a minute.   As far as I can tell, you've heard only from Tom 
>Lane on the steering committee (I may have missed some, though, I've been 
>sick)
>
Exactly. Of the people I heard from, the wind was against.

>   Unless the 5 of us take a vote, Tom Lane speaks for Tom Lane, not for 
>Core.    Also, usually this list or Patches determines by consensus what gets 
>in; the Core only gets involved in very unusual cases.
>  
>
That's why we are holding an open thread on the "how" in "hackers". I'm 
assuming that once the "how" is sufficiently resolved, and the 
implications understood, everyone can make a better decision on the "do 
we at all".

             Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting
http://www.lingnu.com/

Re: [HACKERS] What can we learn from MySQL?

Jim Nasby <jim@nasby.net> — 2004-04-26T17:25:41Z

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,
>   pgsql@mohawksoft.com 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                  jim@nasby.net
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?"

Re: [HACKERS] What can we learn from MySQL?

Jean-Michel Pouré <jm@poure.com> — 2004-04-26T20:13:26Z

-----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-----

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-26T20:41:35Z

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

Re: What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-04-27T01:31:33Z

Bruce asked an excellent question:

> 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.

After watching the traffic on this, the biggest MySQL lesson has gone
largely unmentioned:  that a well-funded, well-marketed, focused commercial
entity clearly associated with the project can do wonders to overcome
feature and technical shortcomings.

At some point (probably there now), I think the lack of a "Postgres, Inc."
is going to hinder adoption.  Companies want to 'buy' from vendors that look
like real, viable companies, and provide them products with support,
training, features, and direction.  With MySQL, you get one stop shopping.
With Postgres, you've got to find and assemble the parts yourself.  Most
CIOs stop there, and start waiting for MySQL to get better before switching
from Oracle.

The other issue is marketing:  in mature software markets, the best
marketing (not the best technology) often wins.  Without a sizeable
marketing budget earmarked for Postgres, MySQL could be 60% as good and
still win, unfortunately.

For those that believe that the Linux kernel is a success model, don't
forget that Red Hat had a lot to do with putting Linux on the map.  And IBM.

For those that look to Apache:  Apache never had a well-established
incumbent (Oracle), an a well-funded upstart competitor (MySQL).  Rob
McCool's NCSA httpd (and later, Apache) were good enough and developed
rapidly enough that they prevented any other HTTP server projects from
getting critical mass.

The corollary to Bruce's question:  where do *you* see the Postgres project
in 3 years?  Market share?  Key features?  Niche?

Related:  does MySQL stumble somehow, or do they keep gaining share?

-andy

Re: [HACKERS] What can we learn from MySQL?

Karel Zak <zakkr@zf.jcu.cz> — 2004-04-27T07:59:54Z

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/

Re: [HACKERS] What can we learn from MySQL?

Jean-Michel Pouré <jm@poure.com> — 2004-04-27T08:43:36Z

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é

Re: [HACKERS] What can we learn from MySQL?

Karel Zak <zakkr@zf.jcu.cz> — 2004-04-27T08:58:30Z

On Tue, Apr 27, 2004 at 10:43:36AM +0200, Jean-Michel POURE wrote:
> >  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.

 I  don't think  it's a  lot of  work. The PostgreSQL  translators spent
 time  with  translation of  things  like  Xlog  messages or  the  other
 "deep-in-backend"  stuff  so I  think  they  will happy  with  someting
 more visible and usable like PostgreSQL installer ;-)

 The important  is if the installer  code support some way  how user can
 selects a language.

    Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

Re: [HACKERS] What can we learn from MySQL?

Tim Conrad <tim@timconrad.org> — 2004-04-27T15:27:54Z

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

Re: [HACKERS] What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-27T15:55:08Z

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

Re: [HACKERS] What can we learn from MySQL?

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-27T15:58:59Z

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

Re: [HACKERS] What can we learn from MySQL?

Tim Conrad <tim@timconrad.org> — 2004-04-27T16:07:11Z

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

Re: [HACKERS] What can we learn from MySQL?

Tim Conrad <tim@timconrad.org> — 2004-04-27T16:12:46Z

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

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-27T16:34:12Z

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

Re: [HACKERS] What can we learn from MySQL?

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-27T16:42:52Z

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

Re: [HACKERS] What can we learn from MySQL?

Tim Conrad <tim@timconrad.org> — 2004-04-27T16:57:46Z

> > 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

Re: Upcoming Features WAS: What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-27T17:30:28Z

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

Re: Upcoming Features WAS: What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-27T17:39:52Z

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

Re: Upcoming Features WAS: What can we learn from MySQL?

Tim Conrad <tim@timconrad.org> — 2004-04-27T17:49:22Z


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

Re: [HACKERS] What can we learn from MySQL?

Alexey Borzov <borz_off@cs.msu.su> — 2004-04-27T17:52:01Z

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?

Re: What can we learn from MySQL?

Bruno Wolff III <bruno@wolff.to> — 2004-04-27T18:23:16Z

On Mon, Apr 26, 2004 at 21:31:33 -0400,
  Andrew Payne <andy@payne.org> wrote:
> 
> At some point (probably there now), I think the lack of a "Postgres, Inc."
> is going to hinder adoption.  Companies want to 'buy' from vendors that look
> like real, viable companies, and provide them products with support,
> training, features, and direction.  With MySQL, you get one stop shopping.
> With Postgres, you've got to find and assemble the parts yourself.  Most
> CIOs stop there, and start waiting for MySQL to get better before switching
> from Oracle.

I would expect that technical people (which would be DBAs and application
developers) should be doing this research and reporting the results to the CIO.

> The other issue is marketing:  in mature software markets, the best
> marketing (not the best technology) often wins.  Without a sizeable
> marketing budget earmarked for Postgres, MySQL could be 60% as good and
> still win, unfortunately.

It is not clear that Postgres needs to "win". It needs to have enough people
interested in it in order to continue to significant development. It doesn't
need to have a majority of the market share in order to do this. I suspect
that get a larger market share amoungst some categories of users will
hurt development by requiring more support than they contribute back to
the project.

> For those that look to Apache:  Apache never had a well-established
> incumbent (Oracle), an a well-funded upstart competitor (MySQL).  Rob
> McCool's NCSA httpd (and later, Apache) were good enough and developed
> rapidly enough that they prevented any other HTTP server projects from
> getting critical mass.

Perhaps for a while. There are open source web servers now. A derivative
of AOLserver is used by openACS.

Re: [HACKERS] What can we learn from MySQL?

Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-04-27T19:12:36Z

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)

Re: [HACKERS] What can we learn from MySQL?

Chris Travers <chris@travelamericas.com> — 2004-04-27T19:59:37Z

Jim C. Nasby wrote:

>Maybe also a more generic section about how PGSQL is different from
>other databases. Maybe I'm just dense, but it took me a long time to
>figure out the whole lack of stored procedures thing (yes, PGSQL
>obviously has the functionality, but many experienced DBAs won't
>associate functions with stored procs). Pointing out the documentation
>on MVCC and how it changes how you want to use the database would be
>good, as would links to documentation on what postgresql.conf settings
>you want to change out of the box.
>
>  
>
I think this is a good idea.  And you seem to be suggesting that it 
includes information on differences in nomenclature as well.

>On the other topics...
>I think the biggest service PGSQL could provide to the open source
>community is a resource that teaches people with no database experience
>the fundamentals of databases. If people had an understanding of what a
>RDBMS should be capable of and how it should be used, they wouldn't pick
>MySQL.
>  
>

I think that this is incredibly important.  Many many developers choose 
MySQL because MySQL really does make the effort in this regard.  This 
strategy has helped both MySQL and Red Hat become the commercial 
successes they are today.

>Having a windows port is critical for 'student mindshare'. If PGSQL can't
>play on windows, professors can't use it. Likewise, installation on OS X
>should be made as easy as possible.
>  
>
PostgreSQL *can* play on Windows (via Cygwin) and I am not sure that 
this is so important to student mindshare.  Howener, it is important for 
another reason: a windows port (even one labled "for development use 
only") would go a LONG way towards recruiting new faces into our 
community, as it would lower the barrier to entry for using the database 
(yes, the Cygwin installer because of the ipc stuff is a reasonable 
barrier to entry).

Best Wishes,
Chris Travers
Metatron Technology Consulting

Re: What can we learn from MySQL?

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-27T20:56:59Z

On Mon, 26 Apr 2004, Andrew Payne wrote:

> 
> Bruce asked an excellent question:
> 
> > 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.
> 
> After watching the traffic on this, the biggest MySQL lesson has gone
> largely unmentioned:  that a well-funded, well-marketed, focused commercial
> entity clearly associated with the project can do wonders to overcome
> feature and technical shortcomings.
> 
> At some point (probably there now), I think the lack of a "Postgres, Inc."
> is going to hinder adoption.  Companies want to 'buy' from vendors that look
> like real, viable companies, and provide them products with support,
> training, features, and direction.  With MySQL, you get one stop shopping.
> With Postgres, you've got to find and assemble the parts yourself.  Most
> CIOs stop there, and start waiting for MySQL to get better before switching
> from Oracle.

I'm gonna disagree here.  I think that not having a postgresql inc to go 
to means that by the time postgresql becomes ubiquitous, it will be like 
apache.  no company behind it, every company using it.  I.e. we'll earn 
our stripes one at a time by proving we're the better database for 95% of 
all purposes, and anyone not using postgresql will be behind the power 
curve and doing themselves no favor.  like CIO's who call Open Source 
"Shareware" and believe that .net provides for a more efficient 
programming environment, people who poo poo postgresql will find 
themselves behind the 8 ball in the long run.  No need for a postgresql 
inc to do that, just time, good code, and knowledgable DBAs choosing it 
more and more often.

Re: What can we learn from MySQL?

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-27T21:07:20Z

On Mon, 26 Apr 2004, Andrew Payne wrote:

> For those that look to Apache:  Apache never had a well-established
> incumbent (Oracle), an a well-funded upstart competitor (MySQL).  Rob
> McCool's NCSA httpd (and later, Apache) were good enough and developed
> rapidly enough that they prevented any other HTTP server projects from
> getting critical mass.

This is a followup to my previous message where I mentioned apache, but 
did not really followup on it.

While Apache is and has been wildly popular for bulk hosing and domain 
parking, for serious commercial use, Netscape's enterprise server, now Sun 
One, has long been a leader in commercial web sites.  That has now changed 
too.  While Netscape's server was pretty good, it is simply harder to 
configure, not as versatile as apache, and not as reliable or as fast 
nowadays.  This was not always the case.  There was a time when its 
performance was considered to be much better than apache (I'm thinking 
about apache 1.3.4 or so) and apache configuration was a black art few 
understood.  with modern gui tools for configuring apache, and the 
incredible performance gains the late model 1.3 versions and now 2.0.x 
versions have, it is quickly displacing the more expensive netscape.

Apache did not start in first place when it comes to "enterprise" class 
web servers, no matter how many small personal web sites ran on it.  Most 
commercial companies didn't use it at first.  It too had to "earn its 
stripes" over time and by proving it was better.  Now I know people who 
think Open Source is just so much pie in the sky hand waving philosophical 
candy who think apache and jboss are the bomb.  they'll come around on 
PostgreSQL too, once someone with some foresight points out the advantages 
it has.  and one of its advantages is that it doesn't have a large 
monolithic organization driving development.

Re: [HACKERS] What can we learn from MySQL?

Simon Riggs <simon@2ndquadrant.com> — 2004-04-27T22:46:34Z

On Tue, 2004-04-27 at 21:56, scott.marlowe wrote:
> On Mon, 26 Apr 2004, Andrew Payne wrote:
> 
> > 
> > Bruce asked an excellent question:
> > 
> > > 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.
> > 

Ignore the opposition and focus. 

Look outward, not inward.

Best Regards, Simon

Re: What can we learn from MySQL?

Greg Sabino Mullane <greg@turnstep.com> — 2004-04-28T00:06:11Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
> I'm gonna disagree here.  I think that not having a postgresql inc to go
> to means that by the time postgresql becomes ubiquitous, it will be like
> apache.  no company behind it, every company using it.
 
That's not entirely accurate. Apache has had lots of help from IBM, as well
as a few other very large companies.
 
> No need for a postgresql inc to do that, just time, good code, and
> knowledgable DBAs choosing it more and more often.
 
Sorry, but technical prowess alone is no recipe for success in today's
marketplace. Things are more complex than that.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200404272007
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFAjvXFvJuQZxSWSsgRAjQoAJ4mcK3KHut1zzwFqqbXEUKXBv1i9QCgsdfX
2uftNhAts2CTAEpKmclW4cE=
=ZaY3
-----END PGP SIGNATURE-----

Re: Upcoming Features WAS: What can we learn from

Chris Travers <chris@metatrontech.com> — 2004-04-28T01:22:26Z

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

Re: What can we learn from MySQL?

Chris Browne <cbbrowne@acm.org> — 2004-04-28T02:24:03Z

Clinging to sanity, greg@turnstep.com ("Greg Sabino Mullane") mumbled into her beard:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>> I'm gonna disagree here.  I think that not having a postgresql inc
>> to go to means that by the time postgresql becomes ubiquitous, it
>> will be like apache.  no company behind it, every company using it.
>  
> That's not entirely accurate. Apache has had lots of help from IBM,
> as well as a few other very large companies.
>  
>> No need for a postgresql inc to do that, just time, good code, and
>> knowledgable DBAs choosing it more and more often.
>  
> Sorry, but technical prowess alone is no recipe for success in
> today's marketplace. Things are more complex than that.

Yeah, things _are_ more complex than that.

But consider also that products that are, in essence, commercial
products must be marketing successes in order to persist at all.

In order for MySQL AB to get paid, and in order for there to be
upgrades to the software, it is _essential_ that their products appear
to be vital commercial successes in the commercial marketplace.

There's some $19.6M of vulture capital that expresses exactly how
essential that is...

If they don't achieve the commercial success that the owners expect,
technical prowess or lack thereof is an entire nonissue.

The fact that there are no "vulture capitalists," no "$19.6M of
commercial pressures," and no stockholders means that some of the
vital 'criteria for failure' that exist for MySQL(tm) do not exist for
PostgreSQL.

The criteria for evaluating success and failure _do_ differ.  It is
wasteful of time and effort to slavishly try to evaluate the differing
software on the same criteria.

If there is value in any of this exercise, it isn't in finding
similarities; it is in finding _useful_ differences.  

- Useful differences between how aspects of PostgreSQL are presently
  publicized and how they might be;

- Useful differences between the features PostgreSQL and other
  software that are worth publicizing;

- Useful differences between PostgreSQL and other software in terms of
  "soft differences" such as licensing and cost that are worth
  publicizing.

It is distinctly NOT useful to merely try to find ways to slavishly
emulate what other projects are doing, particularly if they require
substantial political reorganization or a vulture capitalist with
$19.6M to invest.

It's hard to push contributors to a free software project.  A useful
quote:

  "Feel free to contribute build files.  Or work on your motivational
  skills, and maybe someone somewhere will write them for you..."  
  -- "Fredrik Lundh" <effbot@telia.com>

If a 'release manager' is needed, then either you need the venture
capital to pay someone to do that, or some serious motivational skills
good enough to let you convince people that don't "report to you" to
change what they want to do.

The ideal thing to do is to try to motivate people to do things that
they will find interesting and desirable.  I don't see much focus on
that approach; rather the contrary.
-- 
"cbbrowne","@","ntlug.org"
http://www3.sympatico.ca/cbbrowne/sgml.html
Signs of  a Klingon Programmer - 2.  "Specifications are  for the weak
and timid!"

Re: What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-04-28T02:51:08Z

Scott Marlowe wrote:

> While Apache is and has been wildly popular for bulk hosing and domain
> parking, for serious commercial use, Netscape's enterprise server, now Sun
> One, has long been a leader in commercial web sites.

Netscrape/SunONE may have been a leader in some sub-market, but this misses
the point.

Apache + NCSA never had less than 50% market share, overall.

	http://news.netcraft.com/archives/web_server_survey.html

Postgres is in a completely different situation:  95+?% of the world's
databases don't run on Postgres, and it's been this way for a long time.

Also, Apache never had "MyApache", a more popular version that many believe
to be "free" and "open source".

My point:  Apache was successful in a situation that may not apply here.

Does anyone know of an open source project that *has* successfully displaced
a market of mature, established products WITHOUT a commercial entity
providing marketing, support & direction?

-andy

Re: [pgsql-advocacy] What can we learn from MySQL?

Paul Tillotson <pntil@shentel.net> — 2004-04-28T02:56:00Z

On the other topics...

>> I think the biggest service PGSQL could provide to the open source
>> community is a resource that teaches people with no database experience
>> the fundamentals of databases. If people had an understanding of what a
>> RDBMS should be capable of and how it should be used, they wouldn't pick
>> MySQL.
>>  
>>
>
> I think that this is incredibly important.  Many many developers 
> choose MySQL because MySQL really does make the effort in this 
> regard.  This strategy has helped both MySQL and Red Hat become the 
> commercial successes they are today.

I believe that postgres is making an effort here.  I learned SQL from 
the postgres docs found in the first few chapters here:

http://www.postgresql.org/docs/7.4/static/tutorial.html

Those, in my opinion, are excellent, and were way more informative to me 
than anything on the MySQL website (I tried reading there first).  Maybe 
we are aiming for users who had a clue quotient much lower than I, but 
those attain an excellent balance between too short and simple to be 
useful and too long and complicated.

Paul Tillotson

Re: [HACKERS] What can we learn from MySQL?

Chris Travers <chris@travelamericas.com> — 2004-04-28T03:48:38Z

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

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-28T03:51:07Z

Andrew Payne wrote:
> Also, Apache never had "MyApache", a more popular version that many believe
> to be "free" and "open source".
> 
> My point:  Apache was successful in a situation that may not apply here.
> 
> Does anyone know of an open source project that *has* successfully displaced
> a market of mature, established products WITHOUT a commercial entity
> providing marketing, support & direction?

Linux.  It doesn't have a single company behind it, but several.

-- 
  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

Re: What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-04-28T04:24:22Z

Bruce wrote:

> > Does anyone know of an open source project that *has* successfully
displaced
> > a market of mature, established products WITHOUT a commercial entity
> > providing marketing, support & direction?
>
> Linux.  It doesn't have a single company behind it, but several.

Uh, no.  Linux HAD a commercial entity providing marketing, support, and
direction.  Red Hat went a long, long way to making Linux real for
businesses.  They were (are) a well-funded entity, focused on Linux
adoption.  Their early success, in turn, validated the business (a) so
competitors got funded and (b) so established companies (e.g. IBM) started
to pay attention.

(This is not meant to give all credit to Red Hat:  if it wasn't them, it
would have been some other similar group).

So, does anyone know of an open source project that *has* successfully
displaced a market of mature, established products WITHOUT a commercial
entity providing marketing, support & direction?

If not, where's the Red Hat for Postgres?

Good discussion!

-andy

Re: [HACKERS] What can we learn from MySQL?

Jean-Michel Pouré <jm@poure.com> — 2004-04-28T08:13:27Z

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

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-28T15:55:14Z

Andrew Payne wrote:
> 
> Bruce wrote:
> 
> > > Does anyone know of an open source project that *has* successfully
> displaced
> > > a market of mature, established products WITHOUT a commercial entity
> > > providing marketing, support & direction?
> >
> > Linux.  It doesn't have a single company behind it, but several.
> 
> Uh, no.  Linux HAD a commercial entity providing marketing, support, and
> direction.  Red Hat went a long, long way to making Linux real for
> businesses.  They were (are) a well-funded entity, focused on Linux
> adoption.  Their early success, in turn, validated the business (a) so
> competitors got funded and (b) so established companies (e.g. IBM) started
> to pay attention.
> 
> (This is not meant to give all credit to Red Hat:  if it wasn't them, it
> would have been some other similar group).
> 
> So, does anyone know of an open source project that *has* successfully
> displaced a market of mature, established products WITHOUT a commercial
> entity providing marketing, support & direction?
> 
> If not, where's the Red Hat for Postgres?

My point was that once a single company showed it as profitable, other
companies came alone and no one company controls Linux development.  We
have that now with SRA, Red Hat, Fujitsu, and many smaller companies
funding development of PostgreSQL.  (In fact, there were several Linux
companies before Red Hat.)  

Now, if you are asking about marketing, yea, we don't have much in that
area right now, and we need it.  I think your point was that we need a
single controlling company to provide marketing because if there are
many, there is little incentive to market PostgreSQL because all the
other companies are taking advantage of it.  That is mostly true.

However, I would argue that Red Hat providing support was more important
than Red Hat marketing, and we do have that with a number of companies
now, and SRA is going to be announcing world-wide support soon (not just
Japan), and we have other venture capital guys looking a forming companies.

My concern about a single company, as all of us are, is that we kill the
community that created the software, which then burdens the single
company to steer development, leading to disaster.

-- 
  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

Re: [HACKERS] What can we learn from MySQL?

Mark Harrison <mh@pixar.com> — 2004-04-28T18:18:47Z

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

Re: What can we learn from MySQL?

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-28T19:16:11Z

On Wed, 28 Apr 2004, Greg Sabino Mullane wrote:

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
>  
> > I'm gonna disagree here.  I think that not having a postgresql inc to go
> > to means that by the time postgresql becomes ubiquitous, it will be like
> > apache.  no company behind it, every company using it.
>  
> That's not entirely accurate. Apache has had lots of help from IBM, as well
> as a few other very large companies.

but no one company drove the development, and all development was handled 
by the apache group, which is built VERY much like the postgresql global 
development group.

> > No need for a postgresql inc to do that, just time, good code, and
> > knowledgable DBAs choosing it more and more often.
>  
> Sorry, but technical prowess alone is no recipe for success in today's
> marketplace. Things are more complex than that.

Marketplace?  like where you sell things?  PostgreSQL is free, it competes 
outside of the bounds of the "marketplace".  Since it doesn't have to make 
money to survive, it has a different definition of success, and that is, 
to me, that the people who use it and code it find it to be best for their 
uses.  If others join in and use it or hack on it, that's great, but 
postgresql definitely has enough critical mass to continue for many years 
to come with little or no marketing.  Personally, I don't care if 
postgresql captures 1% of the market of 99% of the market, as long as it 
remains the solid, reliable dbms engine it is.

It's success is measured in the quality of its code, not the number of 
users.

Re: What can we learn from MySQL?

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-28T19:23:37Z

On Tue, 27 Apr 2004, Andrew Payne wrote:

> 
> Scott Marlowe wrote:
> 
> > While Apache is and has been wildly popular for bulk hosing and domain
> > parking, for serious commercial use, Netscape's enterprise server, now Sun
> > One, has long been a leader in commercial web sites.
> 
> Netscrape/SunONE may have been a leader in some sub-market, but this misses
> the point.

Not A submarket, THE submarket, enterprise class application server, i.e. 
web commerce and such.  Just because apache hosts hundreds of thousands of 
personal web sites with all static content does not make it a "market 
leader".  When it came to commercial usage, apache still had to fight its 
way to the top.

> Apache + NCSA never had less than 50% market share, overall.
> 
> 	http://news.netcraft.com/archives/web_server_survey.html

Again, if 98% of those sites are personal web sites with static content, 
(they certainly were until a few years ago) and you remove those from the 
counting, then you find out that in enterprise class web servers, apache 
had sound competition it is only now starting to consume.

> Postgres is in a completely different situation:  95+?% of the world's
> databases don't run on Postgres, and it's been this way for a long time.

and some large percentage of the worlds app servers were running on 
something other than apache for quite some time too.

If postgresql was ubiquitous as the database of choice for simple access 
type applications, it would still have to earn its stripes in the 
enterprise one at a time.

> My point:  Apache was successful in a situation that may not apply here.

I agree that the situations aren't the exact same, but they're more 
similar than most people realize.  Apache was never a market leader in the 
enterprise realm until fairly late in the 1.3.x series releases.

> Does anyone know of an open source project that *has* successfully displaced
> a market of mature, established products WITHOUT a commercial entity
> providing marketing, support & direction?

gcc?

Re: What can we learn from MySQL?

Josh Berkus <josh@agliodbs.com> — 2004-04-28T19:30:41Z

Scott,

>Personally, I don't care if 
> postgresql captures 1% of the market of 99% of the market, as long as it 
> remains the solid, reliable dbms engine it is.

I agree that we don't have to have a majority of the market to be 
"successful."  However, there is a very accurate adage in both business and 
politics:  "If you're not growing, you're shrinking."

We need to continue to grow, not necessarily to take over the market, but to 
make sure that we don't disappear entirely.    I don't want to be the 
"betamax of databases".

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Re: What can we learn from MySQL?

Joshua D. Drake <jd@commandprompt.com> — 2004-04-28T20:17:34Z

> We need to continue to grow, not necessarily to take over the market, but to 
> make sure that we don't disappear entirely.    I don't want to be the 
> "betamax of databases".

But betamax was better ;)

>

Re: [HACKERS] What can we learn from MySQL?

Joshua D. Drake <jd@commandprompt.com> — 2004-04-28T20:38:53Z


>>Does anyone know of an open source project that *has* successfully displaced
>>a market of mature, established products WITHOUT a commercial entity
>>providing marketing, support & direction?
> 
> 
> gcc?

Nope.... most big houses will use Intel/Borland/Vc++ or whatever comes 
with Solaris.

In fact, I can not think of a single project that has displaced a 
commercial one, without market force behind it.

Linux won't do it without RedHat/Novell. I would even dare say that 
Novell will be that driving force, not RedHat.

Even Apache has an entity... It actually became much more popular once
that entity came to existence (even though it was a 501).

Another look at Linux shows that it's popularity amongst the washed 
masses didn't really soar until Big Blue (IBM) starting pushing it.

PHP might be an interesting thought, but ASP is used more widely as is 
Java for commercial stuff.


Sincerely,

Joshua D. Drake



> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

Re: What can we learn from MySQL?

Greg Sabino Mullane <greg@turnstep.com> — 2004-04-29T01:30:23Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
                                                                                                                             
                                                                                                                             
> Since it doesn't have to make money to survive, it has a different
> definition of success, and that is, to me, that the people who use
> it and code it find it to be best for their uses.  If others join
> in and use it or hack on it, that's great, but postgresql definitely
> has enough critical mass to continue for many years to come with
> little or no marketing.  Personally, I don't care if postgresql
> captures 1% of the market of 99% of the market, as long as it remains
> the solid, reliable dbms engine it is.
                                                                                                                             
I care. More market share equals more jobs, which equals more people
working on the project. It's all well and good to treat Postgres as
an academic exercise, but at some point the work needs to be applied
to real world stuff. We are competing with real-world, commercial
projects right now, and the success of how well we do will directly
impact this project. Do you think that Red Hat will continue to employ
Tom Lane if Postgres fades away into a footnote and something else
becomes the database of choice for Red Hat? Do you realize that every
time a company chooses us, jobs are created for people who use,
test, and even develop PostgreSQL?
 
I also want to see PostgreSQL succeed in the marketplace because I
am frankly embarrassed that MySQL is considered the
"open source database." The open source community can do a lot better
than that. Not only is Postgres technically superior, but we are now
(IMO) morally superior, as we don't spread FUD and change our license
mid-stream in an attempt to make money.
 
> It's success is measured in the quality of its code, not the
> number of users.
 
Success is measured in constant improvement and growth. I don't want
PostgreSQL to be the best database system around that nobody uses.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200404282124
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFAkFr3vJuQZxSWSsgRAk8IAJ96vN6VuI2dMWmfxWB+yG/CrWTkogCgqBgo
rsUJMoM6oPEJ83ixpaXdvTo=
=zH3B
-----END PGP SIGNATURE-----

Re: What can we learn from MySQL?

Bruno Wolff III <bruno@wolff.to> — 2004-04-29T04:48:48Z

On Thu, Apr 29, 2004 at 01:30:23 -0000,
  Greg Sabino Mullane <greg@turnstep.com> wrote:
> I care. More market share equals more jobs, which equals more people
> working on the project. It's all well and good to treat Postgres as
> an academic exercise, but at some point the work needs to be applied
> to real world stuff. We are competing with real-world, commercial
> projects right now, and the success of how well we do will directly
> impact this project. Do you think that Red Hat will continue to employ
> Tom Lane if Postgres fades away into a footnote and something else
> becomes the database of choice for Red Hat? Do you realize that every
> time a company chooses us, jobs are created for people who use,
> test, and even develop PostgreSQL?

And more support questions get asked taking time away from development.
For companies the net balance is probably in postgres' favor on average.
However, getting individuals to use postgres who have no background
in databases may be a net minus. Hopefully that won't happen. It will
be interesting to see what happens to the support lists after the
windows port is available.

Re: What can we learn from MySQL?

Peter Galbavy <peter.galbavy@knowtion.net> — 2004-04-29T07:10:19Z

Joshua D. Drake wrote:
> But betamax was better ;)

But that was the point the the comment, wasn't it ? It is not always the 
  better technical solution that wins.

With PostgreSQL not being a commercially licensed RDBMS, it is not so 
much about sales but rather "mindshare" (I hate that word, but can't 
think of a better one). Without a suitably high profile the project will 
not attract the potential skills of developers and companies paying 
developers out there to continue moving the feature set and quality forward.

rgds,
--
Peter

Re: What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-29T13:08:37Z

On Thu, 2004-04-29 at 00:48, Bruno Wolff III wrote:
> On Thu, Apr 29, 2004 at 01:30:23 -0000,
>   Greg Sabino Mullane <greg@turnstep.com> wrote:
> > I care. More market share equals more jobs, which equals more people
> > working on the project. It's all well and good to treat Postgres as
> > an academic exercise, but at some point the work needs to be applied
> > to real world stuff. We are competing with real-world, commercial
> > projects right now, and the success of how well we do will directly
> > impact this project. Do you think that Red Hat will continue to employ
> > Tom Lane if Postgres fades away into a footnote and something else
> > becomes the database of choice for Red Hat? Do you realize that every
> > time a company chooses us, jobs are created for people who use,
> > test, and even develop PostgreSQL?
> 
> And more support questions get asked taking time away from development.
> For companies the net balance is probably in postgres' favor on average.
> However, getting individuals to use postgres who have no background
> in databases may be a net minus. Hopefully that won't happen. It will
> be interesting to see what happens to the support lists after the
> windows port is available.
> 

Which is one of the reasons that I think chasing my$ql's market is the
wrong way to go. We need to be looking for oracle/db2 converts... or at
the least informix/progress/m$ or other 2nd tier databases that we are
most likely already superior too. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: What can we learn from MySQL?

Robert Bernier <robert.bernier5@sympatico.ca> — 2004-04-29T13:26:37Z


Robert Treat wrote:

>On Thu, 2004-04-29 at 00:48, Bruno Wolff III wrote:
>  
>
>>On Thu, Apr 29, 2004 at 01:30:23 -0000,
>>  Greg Sabino Mullane <greg@turnstep.com> wrote:
>>    
>>
>>>I care. More market share equals more jobs, which equals more people
>>>working on the project. It's all well and good to treat Postgres as
>>>an academic exercise, but at some point the work needs to be applied
>>>to real world stuff. We are competing with real-world, commercial
>>>projects right now, and the success of how well we do will directly
>>>impact this project. Do you think that Red Hat will continue to employ
>>>Tom Lane if Postgres fades away into a footnote and something else
>>>becomes the database of choice for Red Hat? Do you realize that every
>>>time a company chooses us, jobs are created for people who use,
>>>test, and even develop PostgreSQL?
>>>      
>>>
>>And more support questions get asked taking time away from development.
>>For companies the net balance is probably in postgres' favor on average.
>>However, getting individuals to use postgres who have no background
>>in databases may be a net minus. Hopefully that won't happen. It will
>>be interesting to see what happens to the support lists after the
>>windows port is available.
>>
>>    
>>
>
>Which is one of the reasons that I think chasing my$ql's market is the
>wrong way to go. We need to be looking for oracle/db2 converts... or at
>the least informix/progress/m$ or other 2nd tier databases that we are
>most likely already superior too. 
>
>  
>

I think the pg grassroots are low end users (ie: people with less 
knowledge and budgets than the established parties). Everything of an 
opensource nature has always gained popularity and strength from these 
people.

MySQL has a constituency that came from here. The grass roots are people 
who are willing to invest the energy needed to adopt to change which is 
what pg represents.

Robert Bernier

Re: What can we learn from MySQL?

Bruno Wolff III <bruno@wolff.to> — 2004-04-29T16:22:15Z

On Thu, Apr 29, 2004 at 09:26:37 -0400,
  Robert Bernier <robert.bernier5@sympatico.ca> wrote:
> 
> I think the pg grassroots are low end users (ie: people with less 
> knowledge and budgets than the established parties). Everything of an 
> opensource nature has always gained popularity and strength from these 
> people.

I think some users are, but I think that the ratio of users new to
databases to those familiar with databases is going to be a lot
higher for MYSQL. I think this will also be the case for postgres
users running on Windows once the windows port is available.

As long as people learn and give back by helping other people once they
know more, things will probably be OK.

Re: What can we learn from MySQL?

Chris Travers <chris@travelamericas.com> — 2004-04-29T18:02:19Z

Bruno Wolff III wrote:

>
>
>And more support questions get asked taking time away from development.
>For companies the net balance is probably in postgres' favor on average.
>However, getting individuals to use postgres who have no background
>in databases may be a net minus. Hopefully that won't happen. It will
>be interesting to see what happens to the support lists after the
>windows port is available.
>  
>
I don't see support questions as being that much of a detractor.  Maybe 
if it happens, we can start a Pgsql-newbie's list and initially feature 
those who provide commercial support for the RDBMS?  Understand that 
everyone has to start somewhere, and having a fresh perspective on it 
from a newbie may help make a better project.  We just need a little 
more insulation between newbie support and development (though the lack 
of such insulation is a general strength of open source software).

I personally think that the way to do this is to create a good set of 
documentation which will help newbies with no RDBMS experience begin to 
understand the basics of PostgreSQL.  For better or worse, MySQL owes 
most of their success to the newbies.

Best Wishes,
Chris Travers

Re: [HACKERS] What can we learn from MySQL?

jgardner@jonathangardner.net <jgardner@jonathangardner.net> — 2004-04-29T18:41:59Z

On Wednesday 28 April 2004 01:38 pm, Joshua D. Drake wrote:
> >>Does anyone know of an open source project that *has* successfully
> >> displaced a market of mature, established products WITHOUT a
> >> commercial entity providing marketing, support & direction?
> >
> > gcc?
>
> Nope.... most big houses will use Intel/Borland/Vc++ or whatever comes
> with Solaris.
>
> In fact, I can not think of a single project that has displaced a
> commercial one, without market force behind it.
>

What happens is the software gets to a point where it is commercially 
viable, but very few realize it. Then a few daring people adopt it and 
start making money with it. Eventually, a market for that particular 
software is created, with people who use the software, people who support 
the software, and people who write the software all making money for what 
they are doing.

At this point, it becomes a market vs. market fight. What Open Source has 
proven is that when it comes to the software, having the entire marketplace 
participate in the process is much more effective than having a single 
company hold the keys to it. Our marketing plans are weak (comparatively), 
but our code is extremely robust. That's why when the game reaches this 
point, Open Source starts to win. The commercial software can't compete 
technically. Eventually, our software is so vastly superior to theirs that 
it is no contest.

Case in point: Compare the latest Windows to Linux 2.6 in a technical way. 
No contest, hands down, Linux is superior. It runs on almost any platform, 
it runs almost any software, and it has features that make Windows obselete 
as an OS. Even if Longhorn with all of the jazz was delivered tomorrow, 
Linux would still be vastly superior.

Why does it work this way? It is because with proprietary software, one 
company has to support the entire market. With open source software, the 
market supports the entire market. Open source software scales wonderfully; 
proprietary only works for small markets. Open source software markets can 
literally take over the world; proprietary software cannot.

Linux is already a huge market, complete with everything you'd need to 
evangelize, develop, and use the software. The market for PostgreSQL is 
small compared to Linux, but it is there. We have independent contractors 
and small companies doing for PostgreSQL what Red Hat and IBM are doing for 
Linux. We are seeing bigger companies join the market, and we are seeing 
daily more people joining our ranks as developers, users, and evangelizers.

The difference between PostgreSQL and MySQL is that we arrived here 
naturally, while MySQL had a jump start with the infusion of investment 
money. They are still dependent on that cash and until they can grow beyond 
it, they can't succeed like Linux. PostgreSQL has already grown to a stable 
point. The only way to go is up.

There is a saying in Korean "yong du sa mi" which means "The head of a 
dragon but the tail of a snake". The meaning is that if you start out 
really big, you end up really little. You have to build up slowly, and 
carefully, to avoid becoming just "the head of a dragon". Real dragons take 
many hundreds of years to create.

Here comes the predictions:
(1) Either MySQL becomes like us and the Linux community, or it dies. Signs 
show that this is not happening as long as it is controlled by a single 
company. You can't have a split personality like this. It's a matter of 
time.

(2) PostgreSQL will be superior to Oracle and DB2 in the same way it is 
vastly superior to MySQL. It may not be tomorrow, but it will happen 
eventually.

-- 
Jonathan Gardner
jgardner@jonathangardner.net

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-29T19:26:05Z

We have a novice list already.

---------------------------------------------------------------------------

Chris Travers wrote:
> Bruno Wolff III wrote:
> 
> >
> >
> >And more support questions get asked taking time away from development.
> >For companies the net balance is probably in postgres' favor on average.
> >However, getting individuals to use postgres who have no background
> >in databases may be a net minus. Hopefully that won't happen. It will
> >be interesting to see what happens to the support lists after the
> >windows port is available.
> >  
> >
> I don't see support questions as being that much of a detractor.  Maybe 
> if it happens, we can start a Pgsql-newbie's list and initially feature 
> those who provide commercial support for the RDBMS?  Understand that 
> everyone has to start somewhere, and having a fresh perspective on it 
> from a newbie may help make a better project.  We just need a little 
> more insulation between newbie support and development (though the lack 
> of such insulation is a general strength of open source software).
> 
> I personally think that the way to do this is to create a good set of 
> documentation which will help newbies with no RDBMS experience begin to 
> understand the basics of PostgreSQL.  For better or worse, MySQL owes 
> most of their success to the newbies.
> 
> Best Wishes,
> Chris Travers
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 

-- 
  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

Re: What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-04-30T16:22:11Z

Bruce wrote:

> Now, if you are asking about marketing, yea, we don't have much in that
> area right now, and we need it.  I think your point was that we need a
> single controlling company to provide marketing because if there are
> many, there is little incentive to market PostgreSQL because all the
> other companies are taking advantage of it.  That is mostly true.

Yep, this is one of the key issues.

Right now, there isn't a group of people (with a decent budget) who get up
in the morning and say, "what can I do today to make Postgres more widely
adopted?"  And that's a big problem.  And it's not just marketing:  who's
working on partnerships?  Who making sure all of the ISVs add Postgres to
their list of supported databases?

> However, I would argue that Red Hat providing support was more important
> than Red Hat marketing, and we do have that with a number of companies
> now, and

I think we may have to "agree to disagree" on this.

> SRA is going to be announcing world-wide support soon (not just
> Japan), and we have other venture capital guys looking a forming
> companies.

This is a good step, but it's not the same as a Postgres-focused effort.
SRA's business (and HP's, and IBM's, and Cap Gemini's, and other companies
which are providing support for open source projects) is not about making
Postgres ubiquitous -- it's about selling services.

If a customer came to {SRA,IBM,etc.} with a large suitcase of cash and said,
"will you support Firebird for me?", you'd say yes!

> My concern about a single company, as all of us are, is that we kill the
> community that created the software, which then burdens the single
> company to steer development, leading to disaster.

Understood, and that's the potential catch-22.  This is the problem with
capital:  no smart investor is going to fund a company to promote and
support an project like Postgres if there's nothing to prevent 5 other
investors and teams from doing the exact same thing.  There MAY be a way to
form something that's supportive and respectful of the community, and I
think it's worth trying to figure that out.

Bottom line:  the Postgres project is at a stage where the non-technical
factors (marketing, partnerships) are at least as important as the technical
ones.  Postgres may "lose" because of lacking technology (such as win32
support, though coming soon), but will not necessarily "win" with the best
technology.

-andy

Re: What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-30T16:36:08Z

Andrew Payne wrote:
> > My concern about a single company, as all of us are, is that we kill the
> > community that created the software, which then burdens the single
> > company to steer development, leading to disaster.
> 
> Understood, and that's the potential catch-22.  This is the problem with
> capital:  no smart investor is going to fund a company to promote and
> support an project like Postgres if there's nothing to prevent 5 other
> investors and teams from doing the exact same thing.  There MAY be a way to
> form something that's supportive and respectful of the community, and I
> think it's worth trying to figure that out.
> 
> Bottom line:  the Postgres project is at a stage where the non-technical
> factors (marketing, partnerships) are at least as important as the technical
> ones.  Postgres may "lose" because of lacking technology (such as win32
> support, though coming soon), but will not necessarily "win" with the best
> technology.

Remember, we all came to PostgreSQL because of the community
development, so we can't expect us to get excited about something that
risks that just to "win", as you say.  If we had gone in this direction
with Great Bridge, we would have seriously injured PostgreSQL and it
might not be what it is today.

-- 
  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

Re: What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-04-30T17:01:18Z

Bruce wrote:

> Remember, we all came to PostgreSQL because of the community
> development, so we can't expect us to get excited about something that
> risks that just to "win", as you say.  If we had gone in this direction
> with Great Bridge, we would have seriously injured PostgreSQL and it
> might not be what it is today.

The "direction" I think I'm suggesting is actually not all that different
from Great Bridge.  And to your point, Great Bridge failed yet Postgres
still thrived.

The difference is that you could now correct for Great Bridge's problems,
which include but are not limited to:  timing (4 years has changed a lot for
commercial acceptance of open source), funding ($25m was too much), and
strategy (this is not an quick attempt to copy Red Hat).

I think such a project, with the right parameters, is very fundable.  If
anyone wants to talk about that, you should drop me an email off-list; we're
probably stepping out of topic for the hacker and advocacy lists.

-andy

Re: [HACKERS] What can we learn from MySQL?

Joshua D. Drake <jd@commandprompt.com> — 2004-04-30T18:20:07Z

> 
> The difference is that you could now correct for Great Bridge's problems,
> which include but are not limited to:  timing (4 years has changed a lot for
> commercial acceptance of open source), funding ($25m was too much), and
> strategy (this is not an quick attempt to copy Red Hat).
> 
> I think such a project, with the right parameters, is very fundable.  If
> anyone wants to talk about that, you should drop me an email off-list; we're
> probably stepping out of topic for the hacker and advocacy lists.

Why would someone fund a "new" PostgreSQL project when there are several 
viable commercial entities doing the job right now?

J



> 
> -andy
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

Re: [HACKERS] What can we learn from MySQL?

Andrew Payne <andy@payne.org> — 2004-05-01T14:28:25Z

Joshua wrote:

> Why would someone fund a "new" PostgreSQL project when there are several
> viable commercial entities doing the job right now?

Four words:  "size of marketing budget".

As a technology guy, it bugs me to acknowledge that.  But having lived
through this a few times, it is the way it works.

-andy

Re: [HACKERS] What can we learn from MySQL?

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-05-04T19:04:46Z

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

Re: [HACKERS] What can we learn from MySQL?

Robert Treat <xzilla@users.sourceforge.net> — 2004-05-04T19:06:53Z

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

Re: [HACKERS] What can we learn from MySQL?

Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-05-04T19:46:25Z

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)

Re: [HACKERS] What can we learn from MySQL?

jearl@bullysports.com — 2004-05-04T21:16:48Z

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