Re: Frequently updated tables

"Mohawksoft":

> I don't think anyone who has seriously looked at these issues has
> concluded that PostgreSQL works fine in these cases. The question is what,
> if anything, can be done? The frequent update issue really affects
> PostgreSQL's acceptance in web applications, and one which MySQL seems to
> do a better job.

I think that we'd welcome any suggestions that don't break MVCC. Do you have
any?

MySQL is able to handle this situation -- in MyISAM tables -- precisely
because there is no transaction isolation and they regard 97% data integrity
as "good enough". Essentially, the MyISAM tables are little better than
delimited text flatfiles. That's not an approach we can take.

> IMHO, this issue, a two stage commit based replication system, and a real
> and usable setup/configuration system are all that stands between
> PostgreSQL and the serious enterprise deployment.

There I have to disagree with you. The features you mention may be important
to your clients, but they are not to mine; instead, we're waiting for
clustering, and table partitioning in addition to what's in 7.5. Please
don't assume that all DB applications have the same needs as yours. The
problems you raise are legitimate, but not everyone shares your priorities.

Besides, we already have "serious enterprise deployment." 5 of my clients
are startups which run on PostgreSQL. The .ORG and .INFO domains run on
PostgreSQL. There are two commerical-grade, deployed, ERP systems for
manufacturers which run on PostgreSQL. What is your definition of
"enterprise deployment", exactly?

--
Josh Berkus
Aglio Database Solutions
San Francisco