Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux]

scrappy(at)hub(dot)org (The Hermit Hacker) writes:

| Alot of good points here, and some not so good...last I checked, vacuum was
| still required for Oracle, no?

Does Oracle even have a vacuum? There's the COELESCE command, but it's hardly
*necessary*.

| As for 'front end and report designers'...there are several of them out there
| currently, most, from what I've seen, *look* good.

A lot of them "look good" at first glance. The problem seems to be that the
implementations tend to be spotty and incomplete amongst the packages I've
looked at. None of them are robust or complete enough for most commercial use.

| If there are features within those that you feel are missing, talk to the
| authors, offer to help...

I'm only speaking from one viewpoint: is the product something I can recommend
for commercial use to my customers in the same breath as Oracle or Informix?
Would *I* use it, personally? Of course; I like it, and don't mind getting my
hands dirty. But most companies would balk. They aren't balking at Linux or
FreeBSD, nor are they balking at Apache, so it's not just an avoidance of
open-source software. They *would* balk at the lack of features, in spite of
PostgreSQL's cool stuff, and they'd also balk at the lack of facilities, and
they'll *really* balk on the stability issues.

| What I'd like to see, though, is a detailed version of your list above. For
| instance, what locking issues? Low-level locking that Vadim is working on
| for v6.4?

I'm not clear on the details of what Vadim is working on, but if it's page- or
row-level locking, that'd be it. However, it's hard to responsibly recommend
something that hasn't been released yet. (Hasn't stopped Microsoft, but I try
to be a bit more ethical than they are. :)

| What analysis issues? If we could get the list above with explanations of
| each, then Bruce can add them to the TODO list. Without explanations, some,
| if not all, will sit there forever since nobody will understand *what* is
| being asked :)

Consider my wrist slapped. :)

One thing I think that would psychologically help is to quit comparing
PostgreSQL with mSQL and MySQL. The m*twins are cute, toy databases, and I
suspect that the general perception is that PostgreSQL is already more serious
than either one of those. So enough with those comparisons. Let's start
thinking about comparing PostgreSQL with its *real* competition: Oracle,
Sybase, SQL Server, Informix, and others.

(Horrors! you say. "They're commercial products, how can we compete?" Apache
still has more than 50% of the web market, Linux and FreeBSD are serious
competitors to Solaris and HPs. So we don't have millions of dollars for
marketing. So we don't have hundreds of developers to throw at a project. We
have something *else* they don't have: a bunch of middle-management
business-as-usual MBA-drones.)

So. Let's talk features. (Hey! www.postgresql.org is reporting "Document
contains no data." How am I supposed to pull up the TODO list like this?)

Well, I'm gonna be guessing here, so please pardon me.

Reliability: You don't need me to point out that a lot of work needs to be
done here. These issues are tough ones to counter. Why doesn't pg_dump
actually preserve everything? (It's getting better, I know, but it's not there
right now.) Why do you have to vacuum the database every night? Questions
like that are tough to answer to people's satisfaction, and that's without even
going into things like memory leaks.

Crucial basics: Views---they desperately need fixing up. Foreign keys,
constraints, and SQL-language triggers are critical as well. I think HAVING,
OUTER and INTERSECTS are being worked on. Temporary tables---are those being
worked on? Yes, I know, most of these are on the TODO list already, but their
current state of nonbeing is keenly felt, and hinders the cause quite a bit.

The draws: These are the things that should be distinguishing PostgreSQL from
the rest of the pack. The source code is a big draw, but it's still hard to
grok. A concerted effort should be going on to document the code itself.
Breaking out built-in types into their own easy-to-locate files would also be
good, too; I had to work to find out how the box functions were defined, where
it would have been better to have a built-in-types directory with a file in
there named box.c, for example, with the data representation and the function
source all neatly bundled---then it would be *easy* to use that as a template
to come up with a different type. (Believe me, if datetime had had such a
file, coming up with the equivalent of strftime() for that would have been a
whole lot easier. As it is, I'm still trying to figure out how it's been
implemented with what time I have these days.) There's a lot of clarification
that could be done here as far as making it easy to add user-contributed stuff,
which ultimately means that we can support more types---and that's a big draw.
(Imagine a type called `earthpoint' consisting of latitude and longitude, and
arrange to have a bunch of the point operators work properly; you might have a
northof function, and a westof function, and a distance function. Then you
might add `earthregion' which parallels the polygon type. So much for having
to sell this product to cartographers. I'd love to create it, but right now, I
wouldn't have a *clue* where to put it, or how to start. I might have the time
to read the source tree once I reduce my project load to just two or three, but
that's not going to happen anytime soon.)

Without a lot of the crucial basics and reliability issues addressed,
PostgreSQL is always going to be a big risk compared to Oracle et al, and
businesses (especially IS managers) *hate* risk. Once those are taken care of,
the other features help sell the product, and we can start worry about things
like image and branding and a nice, polished corporate look and Kerberos
support and other frippery like that. :)

(Which reminds me. Is anyone interested in a rework of the PostgreSQL Program
Flow diagram? My first rework is at

http://www.serv.net/~mcglk/postgresql.gif (30973 bytes)
http://www.serv.net/~mcglk/postgresql.jpg (41422 bytes)

([Take your pick.] It's a little unclear, IMHO, so I came up with a second
draft at

http://www.serv.net/~mcglk/postgresql1.gif (56856 bytes)
http://www.serv.net/~mcglk/postgresql1.jpg (43292 bytes)

(Use as you like, if you like.)

---Ken