Re: [GENERAL] Re: [HACKERS] [Fwd: SGVLLUG Oracle and Informix on Linux] - Mailing list pgsql-general

On Wed, 22 Jul 1998, Ken McGlothlen wrote:

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

    I don't know, but I'll check at work tomorrow about this...and
reply accordingly...

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

    And you've, of course, discussed these failings with the authors
of the software itself?  Or did you do like most and just drop the
software as being incomplete?

    The only person so far that I've had experience with, as far as
'front-ends' are concerned, is Teo (PgAccess), who has been very
responsive to users requests for changes and improvements.  I imagine the
rest are similar in addressing requests, or, hell, make the improvement
yourself and ask them to add it into their source tree for future
releases.

    Its an "open software" model...no one person is responsible in
making it do what *you* want, except yourself.

    Its like a few weeks ago, I started playing with Xtrophy's ICQ
client.  It was missing features that I wanted, so I worked through the
code and added them in myself...submitted patches to the authors, which
they've included in the new release.

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

    features are continuously being added and improved...how many
years has Oracle been working on it, and how much money have they sunk
into it?  We've been going, what, 2 years now?

    Lack of facilities?  Front-end interfaces?  They are out there, as
I listed before...they might be missing features you feel are required,
and I don't dispute that...but if everyone just writes them off, then the
author's have no reason, or desire, to maintain them.  Give the authors
feedback, offer them patches so that they don't have to work at adding
stuff you want, but they don't need and feel is a priority yet...

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

    As do we...how many ppl out there have, to date, been severely
hampered by lack of 'row-level locking'?  IMHO, row-level locking will
give us a speed improvement as ppl won't be as queued on their requests,
but I *think* that that is the major thing it will provide...

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

    I don't quite agree here...I think MySQL/mSQL are required in any
comparison, to show what we do have that they don't.  They label
themselves an RDBMS, so I personally think that *not* including them would
be frowned upon by those looking at the comparison as being a slight.

    As for the comparisons, hey haven't been updated since
v6.2.1...I've asked once before, but is anyone actually interested in
working on updating and revising that?

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

    Actually, IMHO, we have something that 'those commercial products'
don't have...a passion and a love for what we do, else we wouldn't be
doing it.  Therefore, our code *tends* to be cleaner and more stable, as a
result...

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

    What currently isn't being preserved?

> Why do you have to vacuum the database every
> night?

    Statistics and database cleanups.  Last I heard, there is working
being done on removing the locks imposed by vacuum for doing the
statistics, and there is talk about doing work such that 'dead space'
where deleted data resided is reused instead of sitting idle until the
next vacuum...

> Questions like that are tough to answer to people's
> satisfaction, and that's without even going into things like memory
> leaks.

    What memory leaks? :)  Actually, alot of work seems to go into
each this aspect prior to each release, so this should be getting *alot*
better...

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

    I keep meaning to work on this, but I'm going to look into getting
PTS/Keystone installed on the server so that our TODO list can be slightly
more dynamic, where someone can claim and comment progress on the various
areas...that might help some...

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

    Bruce has been working on this as he goes along...I don't know if
anyone else is helping him with it though...

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

    Have you looked into what it would take to do such?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org