Re: [HACKERS] OSDN Database conference report (long)

Tom Lane wrote:
>
Thanks for doing it ;)

I have some comments too ...

> One of the
> longest-running parts of the discussion had to do with giving good error
> messages and how it is hard to get friendly messages when you rely on the
> database to do error checking. I thought this pointed up the need we've
> been aware of for awhile to overhaul our error reporting.

One thing I have wished for a long time is _configurable_ error
reporting,
so that I could tell the backent to "set errorlevel to N" and not
receive
any errors below level N

> Tim also had
> a "wish list" for PG that included better admin tools, such as a way to
> see exactly what queries are running; and a way to retrieve all the
> database-generated items in a just-inserted row, not only the OID.
> Both of these have also been on the radar screen for awhile.

or at least allow something like "select * from table where
LAST_INSERTED_BY_ME"
to be fast (are we currently smaprt enoug to stop scam after finding an
unique item,
or is it so, that "select ... where oid=N" still does a full table scan,
even thoug
oid's are uniqe")

> After a fine lunch (all the food was superb BTW; OSDN made an excellent
> choice of hotel), we reconvened to hear David Axmark talk about the
> history and philosophy of MySQL. The only thing that really surprised me
> is that that project is quite young: it started in 1995. Given that Monty
> seems to do the vast majority of the development work, there are not many
> man-years in it, certainly far less than in Postgres. They've done well
> to come as far as they have.

IIRC they already had an ISAM library and mSQL as a sampole
implementation.

> To get back to the technical part of Ann's talk, the thing I came away
> with is a realization that IB did a lot of things pretty similar to
> Postgres. In particular, it sounds like they have a multi-versioning
> model nearly identical to Postgres'.

I thought that was common knowledge here ;)

At least I mentioned it on this list several times in early days (maybe
95-96)
and I'm pretty sure that also Vadim wrote something about their approah
back
then ?

> They also have some ideas we might
> be able to adopt --- for example, their indexes point only to the newest
> version of a row, not all versions.

I seems to be good as an idea, but woul make it somewhat harder to find
tuples
in transactions that are started earlyer than the newest tuple,
specifically in
cases where they have planned to find the tuple using the index.

> It'd be worth our while to dig
> through their code for ideas. However, Ann admitted that they are
> woefully short on internals documentation, so extracting useful ideas
> promises to be painful :-(

Probably it would be easier to have someone spy on their mailing lists
;)

> The final group-wide session featured Mike Olson of Sleepycat as speaker.
> Most of you know that Mike was part of the Berkeley Postgres team years
> ago (if you don't, try scanning our sources for the initials mao) so I
> count him still a Postgres man, even though Sleepycat is currently in bed
> with MySQL. Mike had some *extremely* interesting things to say about
> the prospects for open-source databases making inroads against commercial
> competition. He pointed out that the notion that we have any chance of
> doing so is mostly founded on the success Linux has been having competing
> with Windows --- but that success is founded on (a) a cost advantage,
> (b) a reliability advantage, and (c) an advantage in the applications
> space: Linux runs sendmail, bind, Apache, and all the other core Internet
> server apps, whereas Windows doesn't run them especially well. Mike
> pointed out that Oracle could *easily* afford to give away their software
> for free and make all their money on support contracts (license fees are
> already only 1/3rd of their revenue, so it wouldn't be that big a
> switch).

That implies that their software is _not_ easy to install/maintain.

I have a frustrated friend who set up a linux box for a company to
replace
an win2000 server which did not work (sendmail, squid, firewall, dns,
...)
and who was promised a support contract as well, but as things just work
for
more than ahalf a year without him, he did not get any contract.

> That would make the cost advantage a harder sell. We could
> still make a good case for open databases on total cost of ownership,
> but a key ball to keep our eye on is the ease of installation and
> administration of our servers.

IMHO postgres is easy to install, not only from .rpm biut also using
configure, make, make install

> Much of the differential comes from the
> fact that qualified Oracle DBAs are scarce and obscenely well-paid.
> We have to be sure that Joe Average Unix Sysadmin can deal with our
> servers without much trouble. As for point (b), the news is bad:
> we are *not* up to Oracle standards on reliability. (Mike only said
> that it's unproven that we are up to commercial standards, but from
> here in the trenches I'd say we ain't.)

In my experience "commercial standards" here means usually that if you
have that 2/3 of price support contract, someone will come running to
fix it
if something happens, not that it is bullet-proof.

But I still need that 7.0.3 releas so that my database would allow me to
do a vacuum without restarting after some amount of heavy work ;)

> We need to keep our noses to
> the grindstone on this issue, and even so it's unlikely that we'll ever
> have the same sort of obvious reliability advantage that Linux has over
> Windows, simply because the commercial databases aren't anywhere near
> as bad as Windows.

True. Or at least partially true ;) Some of it can be attributed to the
human nature and to the nature of software failures - if you have a
mission
critical application and you have payd humongous amounts of money for
your
software (and hardware) you are more likely to test thing very
thoroughly
before going production. Also you are less likely to blame (or allowed
to
blame) an expensive product you may have yoursef recommended.

PostgreSQL and other OSS will never have that defence; so we must be
_more_
reliable in order to be perceived as being "as reliable as".

-----------------
Hannu