Re: database file size bloat - Mailing list pgsql-general

From The Hermit Hacker
Subject Re: database file size bloat
Date
Msg-id Pine.BSF.4.21.0004141447120.2807-100000@thelab.hub.org
Whole thread Raw
In response to Re: database file size bloat  (Brian Neal <aceface@bellsouth.net>)
Responses Re: database file size bloat  (Marten Feldtmann <marten@feki.toppoint.de>)
List pgsql-general
On Fri, 14 Apr 2000, Brian Neal wrote:

>
> Maybe you might want to try out MySQL?  A little while ago, I compared
> both MySQL and PostgreSQL to see how they stacked up (for my purposes,
> anyway).  I came to the conclusion that while MySQL is a very fast
> read-only database, it doesn't support transactions, row-level locks,
> stored-procedures, sub-selects, etc.  PostgreSQL has a lot more basic
> database support, but it is harder to install and maintain (in my
> opinion), has worse documentation, and a number of interesting
> quirks...for example, the fixed-size row limitation that can only be
> changed by a recompilation, or the VACUUM problem described here.
> Other issues I had included the way the backend seemed to work...it is
> certainly very demanding when it comes to shared memory, and I had
> concerns about the process pool (whether or not pg-sql could handle
> enough connections) instead of threads, which most other databases
> seem to use.

Few commments ... the 'row size limit' should be gone in v7.1, as Jan is
working on implementing TOAST for that ...

AS for the process pool ... there are two camps here ... if you use
threads, when one threads crashes the server, the server is done.  With
forking,if one backend dies, the server is still running ... in a 24x7
shop, I'd rather the solution that doesn't die cause JoeBlow down the hall
blew out something with his query :)



pgsql-general by date:

Previous
From: Leitor de Listas
Date:
Subject: PRIMARY KEY
Next
From: Haroldo Stenger
Date:
Subject: Does error within transaction imply restarting it?