info on people running postgre

Personally, I find PostgreSQL to be good for non mission critical databases.
I have used it for many commercial sites, but none that are "heavy" usage,
zero down time. PostgreSQL is a fine database with many features, but there
are database recovery/space usage issues that, I think, keep it from being
usable for all applications. The SQL engine is for the most part ANSI
compliant and the SQL translates well to other databases like Oracle. I
don't know about user defined database level functions...those probably
require rewriting. Performance wise, postgreSQL is fast. If there are
probs then you probably have run into the few performance tweak issues that
you can find listed in the archives...

The fact that you are coughing at $2000 dollars probably indicates that the
application isn't mission critical and postgreSQL probably would work fine
as long as you keep in mind that backups are very important in postgreSQL
and that vacuuming often will save you lots of headaches.

-----Original Message-----
From: Eric Enockson <eric@broken.net>
To: pgsql-general@postgreSQL.org <pgsql-general@postgreSQL.org>
Date: Thursday, March 25, 1999 1:59 AM
Subject: [GENERAL] info on people running postgre

Hi,

We have tryed PostgreSQL as the backend of a Java application used to
collect orders and other information. Everything would have been fine but
for the lack of row-level locking, and some problems with processes that go
hanged when locked for to long. Also we have experienced a couple of
corruptions on a table that suffers the deletion and insertion of 46000
records every day, and some sporadic and misterious backend crashes.

Table-locking has forced us to quit from PostgreSQL and move to Oracle. So
if you need a read-only (or single user) database with moderate performance
(any comercial one is faster), PostgreSQL will probably give you what you
need in this other aspects: good SQL, ease of use and administration, really
thin JDBC type 4 driver; and you may find to need more of:

Export/import tools
Backend stability
Crash recovery
Programming interfaces doc.

Best luck,

Juan Alvarez Ferrando

On Thu, 25 Mar 1999, Juan Alvarez Ferrando wrote:

collect orders and other information. Everything would have been fine but
for the lack of row-level locking, and some problems with processes that go

I'm not yet doing anything in a production environment yet, but the next
version of postgresql does has something more advanced than row level
locking, MVCC. I've been running the CVS version during development and it
seems quite a bit faster than 6.4.2 as well. I'm seriously thinking about
scraping my Oracle DB at work and replacing it with postgresql. Why?

One...Oracle is on site license so I'm not out any money if I switch :-)

Two...Oracle is an absolute hog when it comes to memory and disk space.
Here is a look at top viewing an idle Oracle DB on a Solaris system

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
6174 oradba 23 0 33M 12M sleep 0:00 0.18% 0.12% oracle
6166 oradba 33 0 35M 12M sleep 0:00 0.16% 0.11% oracle
6168 oradba 33 0 33M 10M sleep 0:00 0.13% 0.08% oracle
6170 oradba 33 0 33M 10M sleep 0:00 0.13% 0.08% oracle
6176 oradba 27 0 33M 10M sleep 0:00 0.08% 0.05% oracle
6172 oradba 33 0 33M 10M sleep 0:00 0.08% 0.05% oracle
351 oradba 33 0 11M 2944K sleep 0:00 0.03% 0.02% tnslsnr

Three...By adopting postgresql as my primary db I hope to help the free
software community by dealing with problems as they come up and submitting
problem reports. The people on the dev team have always been helpful so
I'm not too worried that I'll get burned.

On a related note. I'm currently working with a local company to automate
their entire business process and GPL the resulting code. Postgresql is
currently the data storage system of the backend. We are betting that a
freeware solution with (hopefully) free software community support will
provide a better solution in the long run than a propritary one. So you
will not be alone in depending upon postgresql.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

On Thu, 25 Mar 1999, Juan Alvarez Ferrando wrote:

Hi,

We have tryed PostgreSQL as the backend of a Java application used to
collect orders and other information. Everything would have been fine but
for the lack of row-level locking, and some problems with processes that go
hanged when locked for to long. Also we have experienced a couple of
corruptions on a table that suffers the deletion and insertion of 46000
records every day, and some sporadic and misterious backend crashes.

Table-locking has forced us to quit from PostgreSQL and move to Oracle. So
if you need a read-only (or single user) database with moderate performance
(any comercial one is faster), PostgreSQL will probably give you what you
need in this other aspects: good SQL, ease of use and administration, really
thin JDBC type 4 driver; and you may find to need more of:

Export/import tools

pg_dump and psql

Backend stability

would love to see more information on this ..

Crash recovery
Programming interfaces doc.

huh?

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Hi

We are using PostgreSQL for an extranet project.
About one hundred small firms will have a Linux server,
and their own intranet (Apache, PostgreSQL, Perl CGI
using DBI). On a once a day basis, each linux box
connects to a central server (same config) and makes
an update.

The update is triple:
- Update the data: get what is new, send what has changed
- Update the CGI programs theirselves
- Possibly, get a patch and apply it so to update
the structure of tables.

PostgreSQL is a nice tool to do this, as we can
schedule the ~100 updates/day. Our small businesses
don't need ultra-tuned and fastest database, and
could not afford them anyway. But we enjoy Postgres'
handling transactions so well.

We vacuum everything every day, and like Pg a lot.
Thanks to the developing community.
Go and use it with no fear!

Fabrice Scemama
Gesnet Consulting / Paris

The criticisms were pretty accurate overall, and to the point.

The Hermit Hacker wrote:

On Thu, 25 Mar 1999, Juan Alvarez Ferrando wrote:

Hi,

We have tryed PostgreSQL as the backend of a Java application used to
collect orders and other information. Everything would have been fine but
for the lack of row-level locking, and some problems with processes that go
hanged when locked for to long. Also we have experienced a couple of
corruptions on a table that suffers the deletion and insertion of 46000
records every day, and some sporadic and misterious backend crashes.

Table-locking has forced us to quit from PostgreSQL and move to Oracle. So
if you need a read-only (or single user) database with moderate performance
(any comercial one is faster), PostgreSQL will probably give you what you
need in this other aspects: good SQL, ease of use and administration, really
thin JDBC type 4 driver; and you may find to need more of:

Export/import tools

pg_dump and psql

Insufficient. Does not dump and restore everything in the DB. I see
constant
complaints about this in these mailing lists.

Backend stability

would love to see more information on this ..

Run a load test and longevity test. Enter the scenario with the mindset
of "I want to see what I can do to break this." I'll bet that if I
started
from scratch, I could crash any PGSQL implemenation in minutes, unless
you folks have done SERIOUS improvements since 6.3.2. (PS - a longevity
test is something that should take more than 5 minutes ;-))

Crash recovery

Consider transaction logging...

Programming interfaces doc.

huh?

Well - how good is your overall documentation? API documentation does
exist,
but lots of other stuff is missing. Explain to me where I can find an
explanation of server error log entries, such as:

Failed Assertion("!(hctl->nkeys > 0):", File: "dynahash.c", Line: 564)
!(hctl->nkeys > 0) (0)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

--
------------------------------------------------------------
Thomas Reinke Tel: (416) 460-7021
Director of Technology Fax: (416) 598-2319
E-Soft Inc. http://www.e-softinc.com