"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

Thu, 10 Jun 2004 10:41:55 -0700
Josh Berkus <josh@agliodbs.com>
Re: Frequently updated tables