From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL advocacy <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] What can we learn from MySQL? |
Date: | 2004-04-23 08:25:58 |
Message-ID: | Pine.LNX.4.58.0404230935570.6454@sablons.cri.ensmp.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers pgsql-www |
> 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(at)cri(dot)ensmp(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Francois Suter | 2004-04-23 08:27:53 | Re: What can we learn from MySQL? |
Previous Message | Jeff Davis | 2004-04-23 08:16:38 | Re: [HACKERS] What can we learn from MySQL? |
From | Date | Subject | |
---|---|---|---|
Next Message | Francois Suter | 2004-04-23 08:27:53 | Re: What can we learn from MySQL? |
Previous Message | Jeff Davis | 2004-04-23 08:16:38 | Re: [HACKERS] What can we learn from MySQL? |
From | Date | Subject | |
---|---|---|---|
Next Message | Francois Suter | 2004-04-23 08:27:53 | Re: What can we learn from MySQL? |
Previous Message | Jeff Davis | 2004-04-23 08:16:38 | Re: [HACKERS] What can we learn from MySQL? |