On Aug 6, 2008, at 10:04 AM, Mike Gould wrote:
I am looking to hear from people that are using PostGres as their
backend in a commerically available product and how much work would
be needed to ensure that our configurations are optimized for each
platform along with normal database routines?
You need to ensure that it's vacuumed and analysed regularly.
Depending on your data update patterns autovacuum in 8.3 and later may
be adequate for that, but it may not be.
What has the stability factor been once installed if the user has
no administrative / superuser access to the database?
I've not tried that, because I want my users to back up the database
using pg_dump. But I have many users who never touch the database, and
they're perfectly stable after several years of heavy (tens or
hundreds of thousands of transactions a day) 24x7 use. I've had one
case of having to do a manual recovery after a system died badly
enough that RAID10 couldn't save the data, but that's it.
In our application, we never allow for deletes to happen, the
records get marked as "deleted", but until a archival process is run
(normally every 2-3 years) the records cannot be removed.
We have used SQL Anywhere in the past and while I know that the
PostGreSQL installation will be more complex than what we currently
have, there are many aspects of the actual database that have made
us look at it as a replacement to SQL Anywhere in our new product
line.
I can say that with SQL Anywhere it is pretty much install and
forget it. I'd like to have it pretty much the same with
PostGreSQL. With SQL Anywhere we use their internal event processor
to manage the database when it is needed. We fully expect that we
will need to write our own external event processor to manage some
of the database maintenance processes so that isn't really a issue.
We will have several hundred installations and what I don't want to
do is significantly increase our maintenance costs with PostGreSQL
to gain some of the functionality that it has (partitioned tables
being one).
Plan ahead for version upgrades. I have many customers still on 7.4,
because the pain of dumping and restoring to a newer version, along
with the related downtime, is too great. There isn't currently any
viable way to upgrade in place (despite the suggestions of "Use
Slony!" that will inevitably appear).
Cheers,
Steve
