> My Name Is Bruce and I'm A Sock Puppet wrote:
> >So you haven't got to the performance testing part yet?
> It's not really an issue. At our busiest site we would have maybe one
> database update to a single record every few seconds for most of the
> day. We have a period of reporting in the morning which prints to a dot
> matrix printer. I'm expecting Postgres to be faster than a dot matrix.
> End of week/season/year can take a while but we're still talking seconds
> under SE. Postgres can take minutes if it likes - copying the data
> offsite over the WAN is the real time hog.

Your right. Our groupware system (OpenGroupware) uses a PostrgeSQL
back-end; and it handles **WAY** more transactions than that without
any problems whatsoever.

PostgreSQL just sucks for LARGE databases because it lacks table
spaces. It also lacks anything resembling real administrative tools.

But you do need to learn it, and tune it, like any other database (which
can be MUCH harder, minus those aforementioned tools).

sending to informix-list

Adam Tauno WIlliams <adam@morrison-ind.com> wrote:

> PostgreSQL just sucks for LARGE databases because it lacks table
> spaces. It also lacks anything resembling real administrative tools.

If the lack of table spaces is really your problem, just wait
for the upcomming 8.0 (beta3 is out now), which supports
this feature.

Walter